avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: DTD compat -- red herring?
Date Mon, 19 Aug 2002 14:26:19 GMT

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.

Thus, there is no full compatibility between containers.

On one hand, it seems that specifying how to extend the Container could 
solve the problems.
But as you correctly point out, it's a too big commitment ATM. And a 
similar approach has already failed IIUC.

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.

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.

Also the standard containerkit stuff would become part of the framework, 
since it would become mandatory.

Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

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