james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Knystautas <ser...@lokitech.com>
Subject Re: Serviceable to Composable changeover
Date Mon, 03 Jun 2002 05:23:49 GMT
Danny,

I agree a ton could be done to make mailets easier to develop.  I like 
the idea of an SDK as testing mailets is very challenging.  Maybe a 
test-kit might be nice... create a slew of messages, and provide a 
framework that tests a given mailet or matcher.  What I am intending to 
do to make mailet development easier was enhance classloading so you 
could have a /classes directory and load mailets from jars in the lib 
directory in the apps/james dir.  Then in theory support reloading 
without rebooting, and you have something approaching servlet containers.

As for the servlet-design thoughts, I think one of the biggest mistakes 
of the original servlet designers was believing they could design an API 
that could be used by multiple protocols.  I started using the first 
preview of this spec 5 years ago, and 5 years later, the servlet API 
still hasn't found a second protocol that it can handle.  Anyway, my 
point is I think newslets would be a great idea, but trying to make 
mailets able to handle both isn't really feasible.

I think the directions of Paul's email only underscore my point.  I 
think the mailet API could stand to use some additions, like providing 
what this mail server's local users and hostnames are, and otherwise 
remove dependencies to Avalon that we have in core mailets and matchers. 
  These kinds of additions to the API would tie mailets to an SMTP 
processing environment.

I kind of like the mail concept of ".war"... I'd suggest we call it 
"mar" (mail application archive), but with Avalon we've already got sar 
and bar, and do we really need another ?ar filetype. :)

Anyway, and to your final points... isn't the mailet API already 
separated from James code?  It's compiled to separate JARs.  The two 
(minor) changes I have on tap for the next version of the mailet API are 
adding attributes to Mail objects, and log-levels to the logging. 
Renaming matchers to interceptors certainly makes it sound more comp-sci 
like, and that might help people used to looking at APIs understand what 
we're doing.  Like I said above, we could stand to add other key 
concepts to the mailet context to support notions in SMTP processing.

I know there's been yet another discussion of tying matchers to mailets, 
but I still don't like the results.  First, most approaches tie us more 
to Avalon, which I'm against.  Second, most approaches also tie a single 
matcher to a single mailet.  Granted we've been unable to provide 
anything beyond this, I'm reluctant to have the API enforce this 
relationship because I think there are alternate ways to accomplish the 
integration betwen mailets and matchers without this tie.

There are my 2 cents for the night, sparked by drinking too much 
Mountain Dew during the NBA game.
-- 
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/

Danny Angus wrote:
> 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