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:07:30 GMT

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
>>>>"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
>>>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 

And does not provide a framework for extension.

>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 

And how is a container goping to know that it has an obligation to do 
this.  An attribute is just an attribute unless recvigized by all 
containers.  The argument of saying "you 
-can-express-it-as-an-attribute" is false.  The container needs to kno0w 
what that attribute implies. Decalraring an attribute is not differnce 
from declaring a wel formulated set of criteria in the type XML - the 
container still has to sdeal with it - or, declare itself as brain dead.

>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).

I agree that the bnotion of validation is the target.  To achieve this 
you need information that you can manage to determin that a component 
can be deployed.  This is called the validation process.  Phoenix and 
Merlin and Fortress need to respect similar validation criteria - the 
notions of extensions as an example.  All we are talking about if the 
ability for Phoeix to upgrade to the level that it understands the 
conocept of a compoennt declaring a stage depedency and the concept of a 
component declaring its ability to servie that stage dependecy. This is 
distincly defferent for the requirement for Phoenix to actually support 
this deployment- and somewhat academic - Merlin will provide these 
deplyment abilities so simply adding a component inside a Merlin 
comtainer inside Phoeinix solves the problem.

>>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.

It already done!
Check out Merlin.

>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).

It's already done.
Checkout Merlin.

>>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. 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). 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.

In the Avalon Meta Model an extension is a component.  You do not need 
to be concerned with extension specifics.  This is a very big difference 
between Merlin and Phoenix.  Merlin deals with extensions as components 
- as such an extension may have depedencies, my have lifestyle 
extensions of its own, my have context dependecies, etc.  Merlin does 
not differentiate facilities in the way that Phoeinix does which changes 
dramtically the way you go abut providing new functionality.

Chers, Steve.


Stephen J. McConnell

digital products for a global economy

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

View raw message