Berin Loritsch wrote:
>I would like to detail the differences between ContainerKit and
>Merlin's Type model. What are the benefits, and what are the
>bad points?
>
A comparison between containerkit and the Avalon Meta Models
============================================================
There are two meta models being discussed here. One is the
containerkit, the second is the Avalon Meta Info Model that
was created as fork of the containerkit model and is used
within the Merlin container.
Differences:
------------
The Avalon Meta Model is strictly concerning with a
component type and does not include any meta-data. The
containerkit package contains meta-info, meta-data and
several utilities the artificially constrain a container
implementation.
As such, one has to ignore the majority of containerkit
before a comparison can be made. The comparable structures
concern the meta-info layer. The differences between the
the two are described below.
Meta-Info Model:
----------------
Both containerkit and the Avalon Meta Model define a set
of immutable classes that collectively define a type of
component. The containerkit primary class is the
ComponentInfo class. The equivalent in the Avalon Meta
Model is the Type class.
The following features are provided under the Avalon
Meta Model. No equivalent support exists within
containerkit.
* The Avalon Meta Model includes support for a component
type to declare a dependency towards an lifestyle stage
extension. This is very similar to the classic notion
of a component declaring a dependency on a service.
However, unlike a service dependency, a stage dependency
is a dependency that must be dealt with by a container at
a different time to service dependencies (hence the
separation).
* The Avalon Meta Model includes support for a component
to declare itself as a lifestyle stage handler - often
referred to as an extension, or extension handler. The
notion of an extension is very similar to the classic
notion of a component's ability to provide a service (i.e.
it's services declaration). As the application of
extensions is a separate concern to the resolution of
component dependency providers, the declaration of a
component's ability to provide extension stage handling
is declared separately.
* The Avalon Meta Model includes the support for default
information associated with a component type.
Avalon Meta Model lifestyle attribute:
--------------------------------------
Lifestyle attributes are declared within the scope of the
component info attributes block. The ability to declare
such attributes is equivalent between containerkit and the
Avalon Meta Model, however, interpretation of some
attributes is required for component type portability.
There attributes are listed here:
Key Value
avalon:lifestyle singleton|thread|pooled|transient
The above summary provides the breakdown of the functional
differences between the Avalon Meta Model and the comparable
sub-set of containerkit. Aside from functional differences, the
processes associated with the two initiatives are different. The
existence of the Avalon Meta Model was brought into existence as
a result of a necessary fork of containerkit. Since that time,
the Avalon Meta Model has evolved primarily as a result of the
user requirements introduced by the Cocoon project, the Merlin
project, and the Fortress project.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
