Nicola Ken Barozzi wrote:
Mixing my views and the results of the James discussion, I have come to the personal conclusion that it would be cool to have:I like this and as I've understood the Avalon framework better, I think this is something we can do with James without a lot of sweat.
- mailet API indipendent on Avalon
* very lightweight, no concerns about config, logging, etc
* it makes possibly unportable mailets
- mailet Avalon profile
* mailets that are also Avalon components, thus gaining
Avalon features
* mailets can be more portable and feature rich
1 cent's worth...
Like Nicola said, we have Avalon independent mailets that function just like the API. Then we allow James to support mailets that implement the Composable, whatever-able interfaces of Avalon... James can pick up on these and call the appropriate methods on the mailet during the mailet lifecycle.
I like this because..
- it keeps the mailet API lightweight,
- it recognizes that the mailet API should not handle all needs of all mailets,
- it allows Avalon-aware developers using James the ability to leverage Avalon, and
- it spurs the creation (within James) of more advanced mailets (dependent on Avalon) that can then give more context and make further mailet API discussions more productive.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
