Noel,
(1st.. that mail was a brain dump of some thoughts I've been pulling
together for a few weeks now, not a clearly defined idea)
> Matchers seem to me to be well-named, except that they can have
> effect, not
> just match. The mailet tag
> <mailet match="matcher" class="mailet" />
> to me is similar to an IF statement. It produces its primary effect by
> returning a filtered recipient list, although it can have side-effects.
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>
IMO not only does that give us the ability to specify limitless parameters
for interceptors, but it also clearly indicates that this mailet will
process mail intercepted by the interceptor based upon its [the
interceptors] own config, whether or not there is any kind of matching
operation carried out.
For instance the interceptor might poll a remote device or query a database
and handle the mail based upon the results. That is conditional
interception, but the condition is not in anyway a matching operation on the
mail being processed.
> > use mail headers ...
>
> How does this differ from what is already provided by the
> MimeMessage.setHeader() method?
Technically not, but conceptually if we provide attribute setters and
getters in the interface, and in the implementation use the mailheaders we
are not compelling mailet container writers to use mail headers. We are,
however, providing a "cheap" easy to implement route which is backwards
compatible with existing repositorys.
>
> > I also wondered if we should support ajp13
>
> Do we really need Yet Another Transport Protocol?
Depends, shoot-me-down-in-flames-if-you-like but one use-case I considered
was this..
"A guy has an application which generates content based upon a URL request,
in order to add interactive email functionality he can use ajp13 to recieve
requests for content from a mailet which marshals parameters in a recieved
mail into a request, and creates a reply based on the response of the webapp
server"
And the other way round
"A webbapp marshalls parameters from the user, and other sources, into a
URL, the ajp13 request causes this to be converted into a Mail object and
injected into James' spool. The response would indicate the success of this
operation"
The idea of using ajp for this is that it exists already and allows non-java
applications to make or respond to these requests, and recieve the
responses.
It allows the mail server and the content server to be remote from one
another, and avoids the limitations of the mail protocols, which dont
provide very sophisticated requests and responses.
> As for the Servlet API, where do you see the mapping?
See Serge's reply too.
I must admit that having taken a closer look at the newest servlet API that
it would appear that sun have kind of backed off on the idea that it should
be a generic API upon which to build processing blocks for _any_kind_ of
server application, and roped their steer to the saddle of http.
Thus I unreservedly withdraw that suggestion. (football and jubilee induced
madness must be creeping in ;-)
> I'd be more likely to view Mailets perhaps as filters (with a null
> response?) than servlets.
I dont see why the LinerProcessor call to mailet.service(Mail mail)
shouldn't be regarded as a request/response, with either a null response, or
a Mail response which would be the original mail modified by the processing,
and ready for the next step in the processor.
Nor why the SpoolManager in its role as the manager of the LinearProcessors
shouldn't like wise see the call to LinearProcessor.service(MailImpl mail)
as an identical request/response
In fact I believe that it should be possible to have interchangeable process
ors and single mailets such that a processor can contain mailets or other
processors, but I need to work out how the spool would spool & de-spool part
processed messages (in response to callbacks from processors/mailets?).
> I'm not convinced that it is necessary to change the Mailet API to a
> subclass of Servlet API in order to decouple the mailet, matcher,
> processor
> package from the James server code.
This was my bad communication, the de-coupling I believe we need is *not* of
the code, but to a certain extent of the Mailet API as a project, so that we
can have asynchronous progress on james and mailet.
To that end it would be nice to have the Mailet SDK contain a complete
simple implementation which could be used by developers working on the
mailet API, mailet developers, and by users who aspire to add a simple
mailet context to their products.
One benefit of this would hopefully be to deliver a complete, internally
consisistent and "sealed" mailet container that could be used to add mailet
processing to any of James' protocols because it would be capable of
performing autonomously whilst being ignorant of specific implemetations.
(Sun these days deliver complete, or extensive, implementations of a number
of API's in those API's swing's look and feel, and Java Mail are two
examples where you can write a lot of your own implementation, or just use
the one provided)
Ideally if a mail spool manager instantiated this mailet container, it would
have to implement MailetContext, create a Configuration, and nothing else.
And finally a package of mailets and interceptors, with a configuration file
should be able to be unpacked by the container and the processors created
from the resulting files, thus de-coupling mailets and their dependancies
from both the Mailet API and from the mail application platform hosting
them. (of course there still needs to be some indication of the order in
which these applications are requested, but the insertion point
specification would be a single line in James config.xml pointing to the
relevant archive)
d.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
