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 13:34:54 GMT
Serge,

If you go back and look, you'll find that my original proposal was:

>   <mailet matcher="Foo[=cond]" class="Bar">
>     <matcher-config>
>       <tagname>value</tagname>
>     </matcher-config>
>     <mailet-config>
>       <tagname>value</tagname>
>     </mailet-config>
>   </mailet>

I changed to the prefix approach after discussion with Andrei, reading the
Avalon code, and considering the code already in James.  It required the
least changes to how James handles init parameters, and does allow "multiple
conf parameters to matchers."  However, if you wish to change James to
expose a full XML configuration to matchers and mailets, that's fine with
me.  On the other hand, aren't you trying to keep a simpler interface than
exposing Avalon's full Configuration to matchers and mailets?

We could do something like this:

   <mailet class="mailetClass">
      <filter class="filterClass1" condition=""/>
      <filter class="filterClass2">
		<param name="condition">condition</param>
		<param name="foo">fooValue</param>
      </filter>
      <filter class="filterClass3" condition="condition">
		<param name="foo">fooValue</param>
      </filter>
	<param name="somename">somevalue</param>
      <param name="othername" value="othervalue" />
   </mailet>

which I like best of all the other proposals so far.  Mailets must have a
class, but parameters and filters are optional (if no filtering, then it is
ALL).  A filter must have a class, but parameters are optional.

I didn't use:

	<somename>somevalue</somename>

because if we ever define a DTD we won't want arbitrary names for the child
elements. So <notify>xxx</notify> would be <param name="notify">xxx</param>.
I did show both attribute or child element for parameters; if we want to
pick just one way, I'd go with the child element approach, but sometimes it
is nice to just have a quick self-closing tag.

	--- Noel

-----Original Message-----
From: Serge Knystautas [mailto:sergek@lokitech.com]
Sent: Monday, June 03, 2002 8:54
To: James Developers List
Subject: Re: Mailet API v2


Noel,

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

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
http://www.lokitech.com

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


Mime
View raw message