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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
