I've said before that I like the idea of Tweety moving to Avalon-Framework as the 'example container'. People can download one zip and 'get' Avalon (one of out biggest problems). A Tweety-like container hardened for J2ME would be cool too.
2,3 - sounds good. Continue finding commonality of packages as and when. Make sure that A-F interfaces are the client API for all. Be ready for other containers in the 2,3 space by other teams (Turbine). Cool.
- Paul H
I would like to propose set of tiered containers and the appropriate compliance
test suites. The approach requires all of us to work together (building community
as Stefano wants), and satisfies the real need for more than one container in
Avalon. It would work something like this:
1) Micro Container--a Tweety like container that can operate in J2ME. It requires
that only threadsafe components be used because it is unlikely that multithreading
will be used in that environment. It is severly limited, and identifies the minimum
requirements for Avalon compliance.
2) Standard Container--the result of merging Merlin and Fortress. It will be able to
support embedding in a larger container (like J2EE) as well as the more robust
component handling (pooling, thread-local, etc.).
3) Server Container--Phoenix. It identifies the requirements for a root level container
that hosts server applications. It will not be embeddable because it is the kernel.
I think that this approach will satisfy the community needs as well as the needs for
different types of containers. It is also important to focus on container/component
contracts in each of these--all the while providing a reasonable default implementation.
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
