avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ulrich Mayring <u...@denic.de>
Subject Re: Requirements for implementing Cocoon Blocks
Date Tue, 07 Jan 2003 14:52:24 GMT
Stephen McConnell wrote:
> 1. i hate über-container - its missleading
> 2. profile based container solution based on a common architecture
>   is a much more useful description
> 3. we can deliver strong webservice support providing we are ready
>   lift an Avalon lock-in mentality, and instead, embrace the abstract
>   concepts of deployment strategy, assembly, lifecycle, lifestyle, etc.
> 4. backed by a rock solid implementation of the Avalon component
>   model
> And none of the above is fantasy - its all based on validated code.
> Now, if we prove you wrong are you ready to streak across the Cocoon
> list wearing nothing but a Avalon cap and big grin?

I'm not sure which type of container you are talking about. Let me 
explain the three types of containers that I can think of:

1) The abstract container

This is a container, that does not do anything by itself, but it can be 
profiled to be an application server (like Phoenix), a web application 
framework (like Cocoon) and a <insert-your-buzzword>-container (like 

This seems doable to me. However, I don't quite see the userland value 
of this. Of course, from a developer's point of view, it's great, 
because the code is much cleaner and there is more re-use. But as a user 
I still have to decide: do I want to run Phoenix? Or Cocoon? Or Merlin?

2) The über-container

As a user I don't have to decide between Phoenix, Cocoon and Merlin 
anymore and there is no userland duplication of components between them. 
There is one container that does everything. This is the container that 
I think will never exist.

3) The wonder-container (sorry, don't have a better name)

This is somewhere between abstract container and über-container. It 
could run as a distributed application on many servers and the component 
developer would deploy his Avalon components into it. Much like a 
webhosting ISP deploys various applications like Perl or Apache into his 
wonder-container called OS.

Then there are applications like Phoenix or Cocoon, which could access 
those components. The developer of a Phoenix application or a Cocoon 
site would do exactly the same thing to access those components (maybe 
in Cocoon wrapped by some XSP taglib).

> You don't need give up anyting.
> See below.

> How about:
>                             manages
>                         |--------------|
>                         V              |
>  arbitrary_code --> component ---> container
>                         ^              |
>                         |is a          |
>                         |--------------|

This is a very elegant diagram, so I like it by default. It looks a bit 
like the wonder-container, am I right?


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