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 Mailet API v2
Date Mon, 03 Jun 2002 05:43:00 GMT
> rename matchers as "interceptors"

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.

> use mail headers ...

How does this differ from what is already provided by the
MimeMessage.setHeader() method?

> I also wondered if we should support ajp13

Do we really need Yet Another Transport Protocol?

As for the Servlet API, where do you see the mapping?  Some are obvious
(contexts and configs), but others are less so.  For example, I could argue
the mailets are more like filters than servlets, and there are some things
that just don't seem to map well between a Mailet container and a Servlet

Servlets are based upon a request/response model.  In the case of James, the
request-response is implemented in the protocol handlers.  Oddly enough,
SMTPHandler.parseCommand() seems the closest thing to a servlet's service()
method.  Internally, Collection Matcher.match(Mail) and void
Mailet.service(Mail mail):

 a) don't generate responses
 b) are chained by the container

I'd be more likely to view Mailets perhaps as filters (with a null
response?) than servlets.  A Matcher causes conditional execution and muxing
(effectively generating internal requests).  It could be simulated by having
the Matcher use a RequestDispatcher, but I'm not sure how best to map the
functionality, off-hand.  Processors, I suppose, could be viewed as some
form of filter chain.

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.

	--- Noel

-----Original Message-----
From: Danny Angus [mailto:danny@apache.org]

Paul wrote, (in re. Mailets..)

"Interestingly, this overlaps with some pattern/design issues.  I'll
discuss them, but perhaps it is all pointless as you have a published
API and you are supporting a user community. [snip] perhaps for Maillet2

Its funny that you should mention this.. as you know I'm looking at
developing a mailet sdk version of James, basically a mailet developer
friendly distribution.

I've also got the idea in the back of my head that mailets should be
servlets, not http servlets (obviously) but as the servlet API is designed
to support any protocol I thought mailets could, and probably should, be
built on the servlet API, and extended to include "newslet" functionality to
allow identical handling of mail and news messages.

In addition I'd thought that we should do four other things which point
towards a version 2 of the mailet API,

a) rename matchers as "interceptors" because it is a better description of
their role

b) build a standalone mailet container that developers can easily include in
their own products (but I'm a complete no-hoper when it comes to
classloaders) such that app developers could use it to process mail
generated by their apps before it is sent, or mail delvered to their app by
any means, particularly other than by built-in SMTP reception.  This should
support at least, dynamic re-configuration of processors (classloading)
and mailets, and when complete could be used to replace the existing SMTP
mailet context and add a mailet context to NNTP.

c) use mail headers, or some other method which doesn't depend upon anything
other than the mailet API, to allow the attachment of serialisable
attributes to mails, after all thats what X- headers are for.

d) create a wholly encapsulated method of deploying mailet applications
(a-la .war files), such that it would include its own mailet processor
configuration(s) and the only config needed in James would be to specify an
entry-point, using "to processor"

(slightly OT I also wondered if we should support ajp13 to allow other
applications to insert mail into the spool, and to allow mail to request
stuff from other ajp apps. but I've not looked at the ajp spec to see if its
suitable for this role)

I don't expect I'll have time to do much of this, or any of it very fast,
but I do believe we should ..

1/ think about separating the mailet API from the James code
2/ discuss the shape of mailet API version 2


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