james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: Mailet API v2
Date Mon, 03 Jun 2002 12:25:39 GMT
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:
> <mailet>
>	<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>
> </mailet>

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|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