You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Serge Knystautas <se...@lokitech.com> on 2002/05/01 03:47:15 UTC
Re: [Fwd: Re: Mailet API]
Ah, very interesting. Seems very reasonable to me. +1.
I would like to make one more near-final release of James (with proper
avalon releases and any additional few bug fixes) before we start
changing the mailet API.
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/
Steve Short wrote:
> For consideration:
>
> c) allow mailets (and matchers?) to log messages at levels other than info,
> i.e. debug, warn, error, fatal etc.
>
> Cheers
> Steve
>
> -----Original Message-----
> From: Serge Knystautas [mailto:sergek@lokitech.com]
> Sent: Tuesday, April 30, 2002 12:46 PM
> To: James Developers List
> Subject: Re: [Fwd: Re: Mailet API]
>
>
> I think I've sent around my thoughts on this, but here goes anyway.
>
> a) I would like at some point to change the mailet API to have object
> attributes on the Mail object (e.g., add getAttribute(String name),
> setAttribute(String name, Object value), remoteAttribute(String name)).
> This would let you pass information between matchers and mailets, and
> mailets and mailets for that matter.
>
> b) the CommandForListserv/AvalonListservManager is a bad design pattern
> IMHO (although I did write it). Matchers are supposed to be convenient
> ways to component-ize functionality you might want to use in multiple
> mail apps. Checking the remote IP address, looking up a blacklist via
> DNS, checking a header, etc... these are great checks that anybody
> could use, and make great matchers.
>
> I think if you're doing something so functionally-specific as
> CommandForListserv does, you should just use the All matcher and have
> the Mailet do all the work. There's nothing a matcher can do that a
> mailet can't, and I don't think we need to change the API to make
> mailets have a default... I think this makes the API more complicated
> without simplifying configuration in most cases. I mean to write a
> decent listserv soon and will likely squash/deprecate the command for
> listserv matcher since it is a bad example, IMHO.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>