Noel J. Bergman wrote:
The lifecycle of Servlets, HTTP Servlets, JSPs, even Portlets and SIP
Servlets are similar. But let's take a look at these others ... consider:
Matcher: asynch stateless message router based on recipient lists
match(Mail) method
In the current APIs the matcher is not a router, only a matcher/selector.
And I don't understand the "asynch" part of this definition. You call
the service(Mail) method and it process the Mail synchronously. What is
asynchronous?
Mailet: asynch stateless message transformer/broker -- "the app"
service(Mail) method
Again I don't see how it is "asynch": the only asynch part is how we
decided to implement it in james using the JamesSpoolManager.
In-protocol Handler API:
Stateful and synchronous
I don't think we want to put the current handler api as part of the
mailet apis, but I think it worth anyway discussing this
stateless/stateful synch/asynch topic.
The current handlers are not stateful, they are stateless like the
mailets. We should also make sure they are threadsafe like mailets
because they could be used for multiple connections at the same time.
And they are synchronous as the Mailets are: you call a method and wait
for it to finish: no callback here, no callback in the mailets.
Arranged in a chain similar to a Filter Chain
onConnect -- connection from remote client
on<Command> -- receipt of a specific command
onMessage -- receipt of a completed message
onMessage is really similar to what we do in the Mailet.service method.
on<Command> is what we should avoid in the Mailet APIs, but I think that
an "onEnvelope" receiving only the Mail part (without message) would
already be something that would give us the opportunity to refactor many
mailets to use this method instead of the whole "service" and would let
us to use it early in the processing or in processing that do not care
of the included MimeMessage.
Please note that this is only an example and something to be analyzed
and discussed much more.. But I think we should not exclude this
possibility now.
They have in common the thing that you don't like: the
"onMessage/match/service" method, which takes a completed message. The SMTP
protocol handler is one source for such messages to the Mailet container.
So is FetchMail. So is the NNTP protocol handler. So could be IMAP or
Jabber. Etc.
The Mailet pipeline deals with messages and routing, and is independent of
protocol. It could not care less how messages are inserted into the spool.
As you noted, a Mailet Container is protocol independent. There is a
specific contract that the container has with its components. The contract
that exists with protocol handling containers and *their* components
(in-protocol handlers) is different. It would be entirely unreasonable (and
quite poor design) to insist that all containers implement both contracts.
Can you summarize the 2 contracts?
I don't agree on the stateful/stateless and the asynch/synch differences
you reported, but maybe there are other critical differences. We should
really create a list of the 2 scenario peculiarities.
As I said, more and more we're moving to handle filtering in the
protocol
handlers, and have just "application" type code in the pipeline, e.g.,
mailing list managers, delivery support, etc.
But that is JAMES specific. I am not interested in JAMES.
We have already said that if there is interest in the in-protocol handler
API, that we'd be interested in exploring it, too. But we would be talking
about three things:
- Mailet API
- Handler API
- Common Services
I'm curious to see if Common Services turns out to be the most contentious
part.
Well, maybe we can split the whole thing in the 3 "package" you define.
For me it means renaming "Mailet API" to "Common Services" in my mind
and keep talking about how to provide common services that could be
defined once and be used both in the protocol, in the spoolmanager or
for the email client inbox rules.
Stefano
