On Nov 30, 2007 10:10 PM, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin wrote: > > > > Noel J. Bergman wrote: > > > Yes, Robert, I have looked at it as one of the options for future > spooling. > > > However, there are issues and it may not be the easiest and most > appropriate > > > solution. > > > > > > The requirement for transactionality at the processor level is > important. > > > Using just a database for both spool and message store is easier than > having > > > both JMS and database, and thus requiring XA. > > > > > > There are also issues related to filtering. JMS has a static definition > of > > > filtering, which does not serve the needs of our spooler. > > > > i'm not proposing to replace spooling with JMS, just to provide an > > easier way for JAMES to interoperate > > So let's follow this through ...
you say that just i started to have some fun :-) ...if it's real work then i might as well head back to dull-but-worth IMAP... > what's the goal? my goals? 1. to see how long it would take me to code basic integration with JMS using ActiveMQ 2. to stop having to tell users to take a look at the fetchmail and use that as example integration code 3. to understand more about the entry of JAMES project goals? TBD given the positive reaction, i was planning to drop the code into trunk as an experimental module and then see where developers take it. if that's nowhere then it can be deleted (together with the other unwanted stuff) on the 3.0 release branch. > What would ActiveMQ provide in this regard? an easy, embeddable open source JMS implementation with local brokering > Interoperate with what? JEE via JMS > I am all in favor of > supporting additional protocols, e.g., XMPP, but a message is just content. true > What is the envelope? What is the routing info? We can expose a service > (listener) that supports the protocol, but what happens next? :-) those were the questions which faced me this evening. i ended up with a proof-of-concept with the tough questions factored out. i was hoping to ask everyone else those questions but IMHO it's be easier with code... > Right now our > internal spooling is based entirely on the SMTP envelope. We can > generalize, of course. We could have different pipelines, in fact, with > relatively little effort. i don't quite see the collective vision begin the pipelines, mailboxes and so on (but that's probably just me) - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
