avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: DTD compat -- red herring?
Date Tue, 20 Aug 2002 01:38:57 GMT


Nicola Ken Barozzi wrote:

>
> Peter Donald wrote:
>
>> On Tue, 20 Aug 2002 00:26, Nicola Ken Barozzi wrote:
>>
>>> Peter Donald wrote:
>>>
>>>> On Mon, 19 Aug 2002 23:44, Nicola Ken Barozzi wrote:
>>>>
>>>>> We want to get an agreement on what to do for the present and future
>>>>> with regards to unified Component Model, Merlin, Fortress, 
>>>>> Phoenix, et
>>>>> all.
>>>>>
>>>>> "Discussions get forgotten, just code remains."
>>>>>
>>>>> I will strongly oppose and veto any "compromise".
>>>>> I want the *solution*.
>>>>
>>>>
>>>> The only real solution is to use the ContainerKit model. With it 
>>>> you get
>>>> will compatability between all the containers. Phoenix will use it
>>>> directly while Merlin will load it through its own Type loader. If you
>>>> choose to use Merlin specific xml format then you will be bound to
>>>> Merlin.
>>>>
>>>> What is the problem with that?
>>>
>>>
>>> IIUC Merlin has features that Phoenix doesn't have (and viceversa).
>>> If I write a component that uses these "features", it will not run in
>>> other containers.
>>
>>
>>
>> The ContainerKit model does not state anything about these 
>> "features". It gives a mechanism to define metadata and extend that 
>> metadata with attributes.
>> A container can decide to add "features" by handling specific 
>> attributes and components can declare those attributes. The conatiner 
>> can also decide to handle specific types of components. ie if object 
>> is Persistent then call Persistent.persist()
>>
>> Some of these features are required by container and we would need to 
>> standardize an attribute name to indicate required "features". 
>> However as soon as you require such a feature you loose strict 
>> compatability (though other containers that support feature can still 
>> run component).
>
>
> Yes, I understand. 


Not in the case of Merlin.  
Merlin handles extensiuons as components.  As such the restrictions are 
simply limited to the obligation for the extension compoent to declare 
the lifestyle stage it handles.

>
>
>>> We would all like Components that run in *all* Containers
>>> But we still have and want to have different Containers that have
>>> proprietary semantics. And this creates problems in portability, since
>>> it has happened that some James Components are tied to Phoenix specific
>>> things, and they didn't even realize it.
>>>
>>> - How can I run Merlin-specific components in Phoenix?
>>> - How can I run Phoenix-specific components in Merlin?
>>> - How can I be *aware* that I'm using Container specific stuff versus
>>> Avalon baseline?
>>>
>>>
>>> IMHO it would seem that the first two points can be done using a 
>>> correct
>>> Container hierarchy.
>>
>>
>>
>> possibly. We need to figure out a way to dynamically compose services 
>> for that to work but thats certainly possible (actually I just posted 
>> something about this onphoenix list).
>
>
> IIUC Merlin gets around doing this, am I correct Stephen? 


Yes.
Merlin has a complete servie assembly sub-system.

>>> And that the last one by defining a standard way of *describing*
>>> extensions (ie in what "context" they are made and what they need) and
>>> keeping this description physically separate from the standard
>>> containerkit descriptor.
>>
>>
>>
>> Thats sorta what I was saying. 
>
>
> In fact I'm trying to see the good in all the proposed ideas :-)
>
>> Except that I am not sure I would want to standardize the format of 
>> the extension descriptor (ie a Foo-persistent.xml is gonna look much 
>> different from Foo-instrument.xml). 
>
>
> Hmmm... 


The only issue is for Phoenix to throw the exception

    try
    {
          // do classic Phoenix stuff
     }
     catch( ValidationException ve )
     {
         final String error =
             "Sorry, Phoenix isn't as advanced as some other Avalon 
containers."
           + "Phoenix does not support"
           + " * extensions"
           + " * dynamic context"
           + " * default configuration"
           + " * auto assembly";

        throw new ValidationFailure( error );
    }

>
>
>> However a standard way of defining that the component supports or 
>> requires a "feature" seems possible. However the exact semantics of 
>> the "feature" is left up to container/feature writer. They should 
>> feel free to do it however the hell they like.
>
>
> Generally speaking, yes, I agree.
> But Avalon has core concepts like lifecycle, roles, etc.
>
> Since these are concepts common to all Containers, we can still find a 
> common way of telling the Container that the Component wants to have a 
> certain lifecycle handled and certain roles given.
>
> Again, IIUC this is what Merlin tries to do. 


Not only "tries" but "does".
The Merlin architecture cleanly deals with the complete set of 
depedencies for components based on the case requirments from a spectrum 
of external projects.

>
> It makes the contract between Components and Containers more solid.


Exactly!

>
> I do agree that this is not all there is to it.
> But I think that there are extensions to the core Avalon concepts that 
> can be supported by generic Containers. 


At least validated.
Implemetation support should be considered as something seperate.

>
>
> So we would have in the contract three descriptors
> - descriptor
> - standard extension descriptor
> - component-specific container descriptor


This will work providing the standard descitor includes the fundimentats 
- and that includes extension.

>
> -- This makes it clear to the writes of the Component, that in the 
> first case his component is safe to work in all the containers.
> -- If he uses a standard extension descriptor he must supply the 
> extension classes to the Container that supports them.
> -- In the last case, he necessarily has to write his own container.
>
> So we can also have an upgrade path.
> A feature can pass from being a standard extension to part of the core 
> if it's deemed good enough.
>
>>> Also the standard containerkit stuff would become part of the 
>>> framework,
>>> since it would become mandatory.
>>
>>
>> Thats largely where I am going. In a month or two I hope to have 
>> tested it thouroughly enough that it can be put up to vote.
>
>
> I was quite ignorant on what you were doing, maybe because I missed
> the thread about this plan. 


*cough*, *cough*

>
>
> I would like to hear  from the Merlin2 author why he thinks that the 
> current descriptor format is not good enough for extensibility, thing 
> that Peter denies. 


In Avalon land we are relatively familir with the notions that a 
componet may have depedencies and that abnother componet may declare 
that it provides services to match these dependecies.  As far as 
meta-level management is concerned, the original solution was Phoenix - 
a linear service management architecture.  In more recent times, Merlin 
- a hierachical container based service management system has been 
introduced.  The Merlin system specifically address the user 
requirements from several projects - including Cocoon, Fortress/ECM, 
James, and a number of projects outside of the Avalon community. 
 Firstly, these requirements called for a much more flexible solution 
that possible under Phoenix - for example, the ability to 
programatically create and deploy a kernel - the ability to deal with 
componet extensions, the ability to deal with context criteria.

The developent of Merlin 2.0 has carefully and continusly seprated the 
core meta-info model fro the Merlin framework.  This seperation has been 
driven by the collabopration with the Fortress effort and the desire to 
establish container idepenet intoperability (including integration of 
Phoinix into the suite of inteoperable container candidates).

The result of this process is:

   - A container independent meta-info model that supports
     the requirements of the Fortress project, Phoenix and
     Merlin.

   - The Merlin system, a simple kernel supporting a container
     hierachy - a hierachy enabling the dynakmic integration of
     specialized containters such a Fortress, a comtainer model
     that support the dynamic mangement of new omponent types.

As outline in an ealier email - the containerkit descriptor format is 
inadequete with respect to the user requirements on which Merlin is based.

   http://marc.theaimsgroup.com/?l=avalon-dev&m=102979805431045&w=2

Most imprtantly, Merlin and the Avalon Meta Modle is a collaborative, 
user driven iniative.

Cheers, Steve.

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




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


Mime
View raw message