Noel J. Bergman wrote:
Your idea that James could detect and support additional lifecycle methodsThe subject of Mailet Specification is one worth discussing. Steve mentioned the "contract" between a Mailet and its container. In order to achieve portability of Mailets between containers, it is essential that this contract be clearly defined. I would expect the Mailet Specification to address this contract, as well as the API, and possibly packaging and deployment methodologies, too. (As per the servlet spec.)
is something that we can consider as needed. First, though, I'd like to
ensure that we have a really good Mailet Specification for portable Mailet
containers. Note that I said "specification", not API.
There seems to be doubt in some people's minds as to whether Mailet portability between containers is really a goal. I suggest that there is no point in defining the Mailet API/spec as a separate entity to James unless complete portability is taken as a given. What is the point of having another Mailet container if my James Mailet won't run in it? Is it really a Mailet container if it won't run my Mailet? Why would anyone want to implement an alternative container if existing Mailets wont work in it? They might as well come up with a whole new idea of their own.
I have no opinion on whether or not it is a good idea to treat the Mailet API as a distinct entity. If that is what others want (and I think it has already been decided that they do), I'll get on board. However, Mailet portability is a *must* if we are to do this.
(If you save up all the 2c contributored by myself and others on this list, you could be *rich* in a few hundred years!)
;-)
Cheers
ADK
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
