Stephen McConnell wrote: > > > Steve Brewin wrote: > <snipped>
> > As I understand it, different containers vary in their > 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 > > accommodate 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. The current Mailet lifecycle is init, service, destroy. To reconfigure, the container could simply send a destroy followed by an init to effect reconfiguration. Indeed for (1) backwards compatibility with existing Mailets and (2) 'cos the Mailet API is not bound to Avalon so should not be dependent on it, it would have to use this as the lowest common denominator. Exposing more granular lifecycle events which Mailets may optionally support (possibly discovered through introspection) would enable efficiencies during reconfiguration, such as retaining expensive non-reconfigured resources, or resources which must maintain context. Is it worth the effort? Not sure. If there is another clean way of 'parking' resources during destroy and 'unparking' during 'init', then no, otherwise yes. > 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. That would be something worth examining. Any links to the conversations? Cheers, -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
