> <danny> > modify the handler for incoming SMTP such that it could be extended by > "verb classes" to support new SMTP verbs. > </danny> > > Unless I misunderstand you, this would allow for custom extensions to the > SMTP protocol. This is not the goal that I am aiming at. I want to avoid > having to have a separate process, with the implied inter-process > communication, for receiving mail.
But if you could lift the verb classes from James it would only leave you with threading and sockets to concern yourself with.. > <danny> > a mailet containing spoolmanager entirely self referential apart from > standard Java & j2ee classes, this again would form the basis for an > embeddable mailet container and mailet development suite. > </danny> > > Again - this might fit with the tuple spaces thing. I think it is a good > thing. I don't thing it precludes the embeddable SMTP listener from being > a good thing, too. No, what it does is to provide a system into which SMTP can put recieved mail, then you deal with that using mailets. And if you have SMTP protocol verbs which know how to spool into the spoolmanager you're 2/3 there IMO. > This, to me, seems to imply that JAMES should be able to receive and send > mail via a number of transport protocols, which in turn implies protocol > abstraction and pluggability. In order to achieve this, a clear interface > must be defined for JAMES to interact with different protocol > implementations. Does this not mean that I ought to be able to > utilise the > same interface to interact with a protocol implementation from > another app? AFAIK yes, but as James utilises a lot of Avalon interfaces and services you may find too many dependancies to make it worthwhile extracting anything compared with simply installing James. > It seems to me to be a small step from protocol abstraction to protocol > re-use - and in no way contra to the design goals of JAMES. True, but its not a high priority goal of the project at this time. > > Certainly, I can see why you might not want to incur the administrative > overhead of a separate sub-project. To me, that is not important. It > would be enough to package protocol implementations as separate > jars. This > would also facilitate the development of alternate mail transports for > JAMES, perhaps allowing JAMES to receive mail from a JMS queue, instead of > an SMTP connection. James could if you wrote a handler for JMS, both recieve and send. The example I'd give is fetchpop which collects mail from POP3 accounts and spools it in James incoming spool, it can be switched on and off, or ommited completely, is self-contained and has no knowledge of James internals, simply of certain interfaces defining services James provides. It would be simple to write another incoming message spooler to recieve or collect mail in any way, and insert it in the spool, after which it is no-longer the concern of the receiving class(es). Likewise it is a fundamental mission for the Mailet API that it should allow mailets to be used to transmit messages from James. We're about to dicsuss and implement changes aimed at making this less James specific (see elsewhere) but both local and remote delivery are, in principle, examples of messages being transmited to other systems (James repository system and SMTP host respectively) -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
