Leo Simons wrote:
> On Mon, 2002-08-19 at 13:19, Nicola Ken Barozzi wrote:
>
>>Leo Simons wrote:
>>...
>
> ...
>
>>>It has been shown that there is need for additional non-standard
>>>lifecycle stages to <insert requirment here> write some components. To
>>>keep these components portable across containers, the code that supports
>>>the extension should also be portable across containers. To make that
>>>happen we indeed need to make sacrifices, mainly feature flexibility.
>>
>>One note. The fact that there would be a common way to specify
>>extensions makes components portable.
>>This is very important, and as you have seen you cannot use Cocoon
>>components OOTB, because it extends lifecycle.
>>
>>BUT...
>>
>>Is it true that we want Components to be portable across containers?
>>
>>If we have nested Containers, it seems (naively maybe?) that if we want
>>to use ComponentX in our ContainerY we can just make ComponentX one of
>>the components of ContainerY, and access the Components from there...
>>
>>ie:
>>
>> ComponentX-(hosts)- |--- ComponentX1
>> |
>> |--- ComponentX2
>>
>> ComponentY-(hosts)- |--- ComponentY1
>>
>>
>>If I want to use ComponentX1 in ContainerY I do:
>>
>> ComponentY-(hosts)- |--- ComponentY1
>> |
>> |--- ComponentX-(hosts)- |--- ComponentX1
>>
>>
>>Which means that exery Component must be distributed with his Container.
>
>
> consider:
>
> Cocoon ---(hosts)--- Fortress -(hosts)--- Phoenix -(hosts)--- ComponentX
> |
> |-(hosts)--- ComponentY
> |-(hosts)--- ComponentZ
>
> ComponentX <---depends- ComponentZ
>
> minimal call stack:
> ComponentZ.compose()
> ComponentManager.lookup()
> Cocoon.lookup()
> Fortress.lookup()
> Phoenix.lookup()
>
> as opposed to:
>
> Cocoon --
> |
> |-(hosts)--- ComponentX
> |-(hosts)--- ComponentY
> |-(hosts)--- ComponentZ
>
> minimal call stack:
> ComponentZ.compose()
> ComponentManager.lookup()
> Cocoon.lookup()
Doesn't seem a big issue.
Lookup should never be long to do, and the stack isn't so deep... ever
seen Cocoon's in Tomcat?
>>Isn't it conceptually similar to what Berin proposed with the
>>****Manager stuff?
>>Doesn't Merlin advocate a hierarchical Container system?
>
> yup, but Avalon as a whole doesn't (imagine building a hierarchy of
> phoenix kernels...) nor is it always a good idea.
>
> "to use this component inside Cocoon you have to include Merlin; to use
> it inside Turbine you have to use it inside cocoon inside Merlin".
> Hmmm....
I don't think we'll have this.
Usually one writes a Component that runs in a Container, and that can
use Components from other containers. But nobody said that they have to
be nested.
Instead of
ContainerX-(hosts)- |--- ComponentX1
|--- ComponentY1
|--- ComponentZ1
|--- ComponentALPHA1
We'll have:
ContainerX-(hosts)- |--- ComponentX1
|--- ContainerY-(hosts)----- |--- ComponentY1
|--- ContainerZ-(hosts)----- |--- ComponentZ1
|--- ContainerALPHA-(hosts)- |--- ComponentALPHA1
Containers are basically "adapters".
If ComponentX1 needs ComponentY1, it gets ContainerY and then narrows to
ComponentY1. There is only one level of indirection.
>>>>ANd would you mandate that it be
>>>>added into all containers or that containers could not implement it using
>>>>alternative strategies?
>>>
>>>
>>>nah. It just seems to me that "the most simple solution that could
>>>possibly work, in 90% of cases" would be nice to have in the framework.
>>
>>Sorry, Leo, but it seems like the ComponentSelector, Excalibur ECM,
>>etc... compromise stuff.
>
>
> there is a clear choice to do it one way (an interface to be extended by
> an "lifecycle extension module" for each of the clearly identified
> "parts"/"phases"/"stages" of the lifecycle), which is thought to be
> best. The compromise is wrt to features (it is not possible to specify
> relationship between multiple modules in the standard system, for
> example, which was a sacrifice made for flexibility).
>
> The ComponentSelector/ECM was allowed in as a compromise to get a cocoon
> release dependent on avalon (or something like that), even when some
> developers felt it was bad design. That's a different kind of compromise
> to me.
Someone still thinks it's bad design ATM, so I don't se a difference.
Until there is real agreement, I will regard this case as an "ECM case".
>>If it works 90% of the time it's just an added feature, not part of the
>>framework.
>
> the framework itself also works only 90% of the time.
Please explain.
>>>The same arguments are mostly true for other potential parts of the
>>>framework (like a common metadata model): there will always be
>>>alternative strategies that have definite advantages in some use cases,
>>>but the benefit of common ground and reusability in 90% of cases
>>>outweighs the downside.
>>
>>The 90% stands now, in some months it may be 50% then 30%... who knows.
>
> yup. But if there is no common ground in these areas the use of avalon
> in general will go from 9% to 5% to 3%....as opposed to from 9% to 30%
> to 90%...
True. This is why I want a standard way of using Components in different
Containers. Maybe Container hierarchy can make this happen.
>>>It doesn't matter whether such a meta model or lifecycle extension
>>>support is dubbed part of avalon framework or if it is called
>>>"framework++", as long as we as a project choose as much of a common
>>>solution as is possible. It just doesn't seem "wise" to have competing
>>>"frameworks" inside the same project. But hey, apparantly that's just
>>>"me" =)
>>
>>We know that in Avalon Containers are Components, both in complexity and
>>featureset.
>>
>>This is why we have many Containers coming up, as we have many Components.
>>
>>I would like to use a container that manages extensions when I think
>>it's right.
>>I would like to write *my* container that does *not* supply extensions
>>where needed.
>
>
> +1. But I want one consistent approach *within* avalon. It really does
> not make sense to have one avalon container do it one way and then have
> another avalon container that does exactly the same thing in a slightly
> different way just because some developers have decided to consistently
> disagree.
If it does exactly the same thing, I also want one only approach.
If it doesn't, we must define rules for interoperability.
--
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]>
