Alan Williamson wrote:
> Looks like we are going to disagree on this issue
That depends on whether you want to agree on standardizing on an API for
in-protocol handlers or insist on conflating the requirements of two
distinct and separate containers.
> This sort of dogma bogged down the early days of the Servlet API; many
> argued that servlets were far more than HTTP. They were right; however
> 99.999999% of all servlets are attached to the HTTP protocol. Therefore
> it quickly made sense to push HTTP functionality into the specification.
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
Mailet: asynch stateless message transformer/broker -- "the app"
service(Mail) method
In-protocol Handler API:
Stateful and synchronous
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
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.
> > 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.
--- Noel
