We have a neat definition of the component lifecycle that is quite rock-solid and useful (http://jakarta.apache.org/ avalon/framework/reference-the-lifecycle.html).
We also have a less formal definition of component lifestyle. There's some stuff in Berin's Developing with Avalon (in http://jakarta.apache.org/avalon/developing/framework.html), as well as in the mailing list archives. I think now is the time to start thinking about a formal definition of component lifestyle. definition: "The component lifestyle defines in which environment the component can be used." analogy: keeping it military-style, you can have many soldiers (components) that basically function the same way (same lifecycle), but where they can be used in different missions (different lifestyle). Some may only be able to work alone (SingleThreaded), while others are good teamplayers (ThreadSafe). Some may be easily made active and inactive (Poolable). Special types of soldiers can be frozen in a cryonic (sp?) chamber, transported across the star system and then be thawed and sent back into battle (Serializable). hmm...help? Basically, we define a lifestyle through the implementation of marker interfaces, just like we do with the lifecycle. Candidates: Runnable ThreadSafe SingleThreaded Poolable Singleton (new) Serializable Defining these well means that the ComponentManager can adapt its behaviour based on the allowed lifestyles. Runnable is pretty much related to ThreadSafe and SingleThreaded. You could see ThreadSafe as our replacement of Runnable. ThreadSafe, SingleThreaded and Poolable are well-known and in use throughout avalon. They're cool; we've defined what coupling of these three with the various lifecycle interfaces means. While the Singleton pattern doesn't really fit in well with the Component/Container/ComponentManager idea, taking it into account eases the process of avalonizing existing components (ie it would make integration with Turbine's Fulcrum easier). Serializable allows for storage of component state. In avalon, this state consists of Configuration, Context, Parameters and perhaps some component-specific state that doesn't fit into those three. We could have a Serializable that extends the java interface, and then a utility that would serialize based on configuration, context and parameters. thoughts? - Leo -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
