avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: DevWAv (was Re: Minimum Set of Tags (Revisited))
Date Wed, 09 Apr 2003 06:14:37 GMT

Nicola Ken Barozzi wrote:

> For me it's all hairsplitting and trying to solve it all in one go. 

For me it is about identifying the problem your trying to solve before 
attempting to solve the problem.  I happen to think that there is a 
fundamental flaw in the common denominator approach - you end with 
something that is not usable by anyone.

I see the following four things that are needed - and I have the 
impression that the focus is on (4) without resolution of (1), (2) or (3).

    1. be clear about the objective
    2. identify where your moving from
    3. figure out the possible approaches
    4. move to a solution

1. What is the objective:
   My view:

        Definition of a set of tags that can be used
        independently of any container to provide the
        supplementary meta info needed for any container
        to either deploy the component, or signal an
        inability to deploy

    Berin's view:

        It is the minimum set of tags that are required
        to *define* a component and its role interfaces.
        The minimal set is not intended to provide any
        information that is used for validation purposes.
        There is no notion of signaling the container that
        they cannot deploy the component.

Conclusion - basic objective needs more discussion. If the objective is 
to define a set of tags capable of supporting AF4 then this should be 
stated.  If the objective is to define a set of tags that are restricted 
to the @phoenix @fortress subset then you have add all of the implicit 
semantics introduced by Phoenix and Fortress.  Maybe the objective is 
just for Berin to figure out the tags structure and semantics for 
@fortress - if so, that should be stated.

2. Where are we moving from:

  Components with AF+ECM semantics and without markup
  indicating the implicit ECM assumptions - these components
  will typically fail when used in non-ECM environments due
  to non-declaration of assumptions concerning selectors and
  lifestyle requirements.

  Components with AF+Phoenix semantics are less problematic
  because the Phoenix components include meta-info from which
  a container can adapt to address the assumed semantics such
  as BlockContext and implicit singleton lifestyle.

  Components with AF+Type semantics include meta-info however
  there are four context entries provided by Merlin that create
  a potential for non-interoperability (home dir, temp dir, name,
  and partition).

3. Possible Approaches

  (a) tag based markup
  (b) a common meta-info model

Tag based markup is easier because in principal you can generate the 
meta from the tags.  In practice its not that simple because you cannot 
just say "let's start with @phoenix  because @phoenix carries with it 
implicit assumptions (as described above).  What you can do is start 
with @phoenix plus declaration of the implicit assumptions which can be 
achieved by declaring the Phoenix BlockContext assumptions (context type 
and context entries) and singleton lifestyle.  Another approach is to 
start with ECM and construct a set of tags that make explicit what is 
currently implicit - e.g. a tag on the Serviceable/Composable 
implementation such as

    @avalon.dependency type="whatever" semantics="ECM"

  .. as opposed to:

    @avalon.dependency type="whatever" key="my-key"

If we consider the above two statements - the first statement is simply 
the declaration by a ECM style component that it is expecting semantics 
over and above the AF4 contract.  If we consider the second declaration 
it is clear that an ECM/Fortress implementation would need to handle 
mapping between "my-key" and "whatever".

Why - because we are talking about an @avalon scope and that means 
digging into all of those nasty little details.

Cheers, Steve.


Stephen J. McConnell

Sent via James running under Merlin as an NT service.

To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message