Paul Hammant wrote:
> Nicola,
> 
>>> Kewl.  I find A-F's lifecycle is the easiest thing to market in work 
>>> and out of all of the Avalon projects aspects.
>>
>>
>>
>> I agree.
>> That's why we wrote Tweety, that explains basically lifecycle in a 
>> simple way.
> 
> 
> And it is great.  Are you going to take back your words-in-my-mouth 
> "Phoenix == Avalon RI" jibe?

Are you going to take away the "Phoenix BlockContext == de-facto standard"?
No, because in a sense both of us are right.

Phoenix in a sense has already been seen and used as a RI of Avalon, 
from a server perspective.
I have no problem in saying it, it's true, and you implied it too.

Now, because of the *user* need of Component interoperability between 
Containers, we must define the contracts better, and make any Component 
workable in any container.

  ----


This is the scenario I have in mind:

Let's say I want to use a ComponentA written for ContainerA in ContainerB.


   ContainerA ---(hosts)---(  ComponentA  )

   ContainerB- ?


We have a common descriptor format, so ContainerB can look in the 
descriptor and see if it's capable of running it.

If it can, great, Bob's your uncle :-D

   ContainerB ---(hosts)---(  ComponentA  )

This must not only define the lifecycle needed, but also which Context, 
which keys in the Context, etc are needed, which Merlin does IIUC.

If not, I can see if the Component declares an extension can solve the 
issue. If it does, Bob's your uncle again, and it can get the extension 
handler and use that.

   ContainerB ---(hosts)---(  ComponentA  )
                \
                 \
                  --<  ExtensionA  >

This is done by Merlin/Fortress, and is not mandatory.

Finally, it can happen that something needed is not really doable by 
ContainerB.

It should be able to automatically get ContainerA, and ask him to be 
given a handle to ContainerA.

We'll have:

   ContainerB ---(hosts)---(  ContainerA  ---(hosts)---(  ComponentA  ) )

This info is needed in the descriptor, or in some registry, so that the 
Container can delegate things to a Container that acts as a Component 
that manages our ComponentA.

How can it be specified?

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

Reply via email to