Steve Brewin wrote:
Danny Angus wrote:
My take on the container is that we it to just be there, support our
code,
be free of memory leaks and crashes, and otherwise stay out
of our way.
Agreed. And i don't normally pay it much attention, but with people talking about Merlin I wondered what your idea was.
As I understand it, different containers vary in thier depth of support for the Avalon lifecycle. As I remember from way back, we could dynamically modify configurations if the container supported the requisite, but optional, lifecycle methods - suspend, resume, reconfigure, etc.
While I agree that we should be container neutral, it would be good to accomodate the extended, but optional, Avalon lifecycles into a reworked Mailet API so that it can be leveraged when available.
Just a quick note - you should not need to modify the mailet API because in effect the mailet api is a view on a container - the container is handling the deployment of mailets. The question you are raising concerns the semantics supported by the mailet container implementation as opposed to any computation constraints implied by the api.
Albert Kwong recently sent to me a patch detailing a MailetRegistry that handles the registration of merlin based mailet implementations (without touching the mailet api). This is consistent with the ideas I've discussed with Alexis Agahi (Open IM) - basically that the really interesting scenario is the ability to move james from "application" to "service" and once that is achieved - to be able to use james as just another service available to any other component.
Cheers, Steve.
--
|---------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
