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>