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.
>>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?
>>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...
> 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.
It makes the contract between Components and Containers more solid.
I do agree that this is not all there is to it.
But I think that there are extensions to the core Avalon conceptsthat
can be supported by generic Containers.
So we would have in the contract three descriptors
- descriptor
- standard extension descriptor
- component-specific container descriptor
-- 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.
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.
Also, what Merlin brings in tearms of dynamic resolution, and what
impact it has on systems using Merlin.
Please do it with some code, so that we can see where the issues lie.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
