Alan Williamson wrote:
I agree with the latter, but the former is addressed by the
aforementioned
in-protocol handlers. Perhaps you're just behind the times with JAMES.
I respectfully disagree Noel.
I don't wish to talk about JAMES. Not because I don't value it as a
project but because IMHO it has no purpose on a discussion list about
the Mailet API.
I partially agree with this statement: I don't want us to make the big
mistake to discuss an abstract api without concrete goals.
I think future "implementors" of the API are the one that should
influence the API itself, and that we all (implementors) should work on
something concrete and only after having tested it as working in a real
environment try to standardize the API.
We should start creating a list of limitations of the current APIs and a
list of things we believe should be feasible from a Mailet API user (the
developer) perspective.
Once (if) we'll have agreed what features we want to support and what
features we want to keep out from the apis we can discuss the best api
to provide the required extensibility.
We no more want to talk about Tomcat or JBoss when it comes to
discussing the Servlet API. JAMES is merely *one* container
implementation of the Mailet API - we now have an alternative
implementation in MailCatcher.
JAMES is probably suffering from being only the rooster in the farm; but
that is something we would like to address and offer people a choice
when it comes to Mailet containers.
If one wants to use the Servlet API again as an example, i see JAMES as
the full blown "J2EE" reference implementation, where as the Mailet
stuff, is like the Servlet Containers (ServletExec, Tomcat etc).
So the question boils down to this; does one want to see the Mailet API
grow as a separate project, or is this really a JAMES discussion?
I think we should grow it as a separate project, but I think we should
keep discussing about how currently James Server and MailCacher (and any
other implementation around) is trying to solve commons problem with the
current mailet apis or without them.
To understand better each other we should probably study each other
products. I already download mailcatcher.zip ...
Stefano
