james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Angus" <da...@apache.org>
Subject RE: Serviceable to Composable changeover
Date Sun, 02 Jun 2002 12:02:30 GMT
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
API."


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 would support at least, dynamic re-configuration of processors and
mailets, and when complete could be used to add mailet

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


d.





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