james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Knystautas <ser...@lokitech.com>
Subject Re: Mailet API v2
Date Mon, 03 Jun 2002 12:54:15 GMT

I didn't like the approach you took because you're mixing matcher and 
mailet configuration.  I think Daniel's is much cleaner since by 
configuring things separately, it becomes easier to put 2 or more 
matchers/interceptors in front of a single mailet.

As for naming, I don't really care about matcher vs. interceptor... what 
about "filter"?  I tend to agree with Daniel that "matcher" implies 
something simpler and I tend to agree with Noel that "interceptor" 
implies something more, e.g. doing something.  Since Noel described a 
matcher/interceptor as *filtering* the result sets, does that work for 

Another thing I like about Daniel's config example is that it allows for 
multiple conf parameters to matchers, which is probably overdue.
Serge Knystautas
Loki Technologies - Unstoppable Websites

Noel J. Bergman wrote:
> More later, but I wanted to reply to:
>>I believe that matchers should be renamed interceptors and the config
>>changed to look more like this example:
>>	<interceptor>
>>		<class>my.package.fooInterceptor</class>
>>		<condition>domain=me.com</condition>
>>		<otherparam>somevalue</otherparam>
>>	<interceptor>
>>	<class>my.package.fooMailet</class>
>>	<params>
>>		<somename>somevalue</somename>
>>	</params>
> Please see
> http://www.mail-archive.com/james-dev@jakarta.apache.org/msg02208.html and
> related messages.  According to the scheme Andrei and I discussed, the
> example could be encoded as:
> <mailet match="fooInterceptor" class="fooMailet">
> 	<matcher-config:domain>me.com</matcher-config:domain>
> 	<fooInterceptor:otherparam>somevalue></fooInterceptor:otherparam>
> 	<fooMailet:somename>somevalue</fooMailet:somename>
> 	<mailet-config:othername>othervalue</mailet-config:othername>
> </mailet>
> matcher|mailet-config and the matcher|mailet classname are synonyms in
> context, and just used for illustration purposes.
> I posted the outline of the code changes necessary to support this right now
> in James.  By now Andrei may have put them in, else I can do them this week.
> And I don't especially care what we call matchers, but interceptor does not
> carry an a priori semantic meaning to me.  If they are going to be renamed,
> I'd just as soon call them "conditions": <mailet condition="condClass"
> class="mailetClass" />
>>the interceptor might poll a remote device or query a database
>>and handle the mail based upon the results.
> The problem I have with that sentence is that a matcher is not supposed to
> "handle" the mail; it is supposed to yield a filtered set of recipients,
> which the processor will use with the mailet.  I know that you know that,
> and quite well, but the words used in your description blurred the
> distinction between matcher and mailet.
> 	--- Noel

To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>

View raw message