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()
> 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....
> >>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.
> 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.
> > 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%...
> > 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.
cheers,
Leo Simons
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
