Robert Burrell Donkin wrote:
> > > 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...
LOL
> my goals?
> 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
You are talking about injecting messages into JAMES. One way: provide a
simple wrapper around JavaMail. Sure, we can use JMS and provide a Queue.
Do you suggest that client coding for JMS would be easier, and what happens
when a message arrives on the queue? I don't mean the JMS coding on our
side -- that's trivial -- what do we do with the message?
> > What would ActiveMQ provide in this regard?
> an easy, embeddable open source JMS implementation with local brokering
"This regard" referred to the "easier way for JAMES to interoperate" goal,
which leads to:
> > Interoperate with what?
> JEE via JMS
JEE is about an application intrastructure consisting of containers,
container managed components, protoocols, services. JMS is a messaging
abstraction. JavaMail is also part of JEE. JAMES could use JMS to receive
messages, but as I said ...
> > 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...
OK
> > 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)
Messages arrive into JAMES via a protocol handler (generically, even
FetchMail can be viewed in this category). They move from there into the
spooler by an internal API. The spooler moves messages from one processor
to another until the message is consumed. The processors consist of chains
of matchers and mailets, which do their jobs based on SMTP envelope and
(optionally) message content.
Currently, messages are always started at the "root" processor, but I have
previously suggested that we could make that more flexible, allowing
different entry points for messages. It might benefit FetchMail, for
example, if it could bypass some of the things we do in the root processor.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
