Nicola Ken Barozzi wrote:
Noel J. Bergman wrote: ...I don't care which container we're operating in. And people seem fairly
firm regarding a Mailet API that works well within an Avalon container, but
is not tied to requiring one.
Stephen , all, we have already discussed this at lengths, and the conclusion has been that Mailet API has to be indipendent of Avalon.
This is their community decision, which I totally respect, and that has evident good points too.
One thing that has polluted in the past this decision, IMHO, is that Avalon can easily be regarded as a whole, and Paul has gone to extents to explain this in (painful? ;-P ) detail.
Mixing my views and the results of the James discussion, I have come to the personal conclusion that it would be cool to have:
- mailet API indipendent on Avalon
* very lightweight, no concerns about config, logging, etc
* it makes possibly unportable mailets
I disagree. I think the approach on the Mailet spec provides the highest portability.
- mailet Avalon profile
* mailets that are also Avalon components, thus gaining
Avalon features
* mailets can be more portable and feature rich
Provides less portability (because it requires an Avalon aware container), but is much more useful (because it leverages a formal component model).
The point not addressed in the Mailet discussion to date is the framework for mailet assumptions about the mailet container (Avalon syle or any other style). In particular, the container needs to be able to look at a mailet and ask itself - can I run this mailet and provide everything it is expecting - OR - a mailet container interface is defined across which I can provide an established mailet instance (i.e. bypassing an internal James mailet deployment phase).
Cheers, Steve.
1 cent's worth...
-- Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
