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 11:19:06 GMT

Leo Simons wrote:
> In "my wisdom", current proposals are approaching a point where the
> feature set, complexity, etc, is similar to the one the avalon lifecycle
> propagates.
> Sure, our lifecycle setup is not the fastest, nor is it the most
> flexible, or manageable. The one killer feature of the avalon lifecycle
> is that it is common ground (the other ones being that it is simple,
> stable, documented, supported).
> 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.


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


  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.
Isn't it conceptually similar to what Berin proposed with the 
****Manager stuff?
Doesn't Merlin advocate a hierarchical Container system?

In this way, the only thing that we have to support is how Containers 
expose themselves as Components, ie with the usual lifecycle methods.

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

If it works 90% of the time it's just an added feature, not part of the 

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

> 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 

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.

Why can't we just build a common set of execution environments 
(server-standalone ala Phoenix, commandline and Ant task ala Merlin1, 
servlet embeddable... etc) and then populate it with the required 
Containers (Fortress, Merlin2, Phoenix"Blocks", ECM)?

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