> What a timing! we are currently discussing exactly what is the best way > to allow Cocoon to be run as a Mailet since that requires some > architectural additions in the way Cocoon abstracts input and output.
Excellent, perhaps we could help you by mentioning that the Mailet API is about to go into a new design cycle heading towards V3, so check out our initial ideas on wiki and if there are any more things you'd like addressed during this process mail the james-dev list in the time honoured fasion. > The cocoon architecture is designed to be abstracted from the input and > output, but currently we implement two abstractions: servlet API and > command line. Mailet API will be the next since Nicola is very > interested in this as well. I think he's becoming a bit of an evangelist for James :-) > The Cocoon dev team will be definately happy if the James people (or any > other interested party) could help us in the process of deciding what is > the best way of offering Cocoon services as a mailet. I'll lurk on the cocoon list. d. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
