Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
To: avalon-dev@jakarta.apache.org
Path: not-for-mail
From: Ulrich Mayring <ulim@denic.de>
Subject: Re: Requirements for implementing Cocoon Blocks
Date: Tue, 07 Jan 2003 15:52:24 +0100
Lines: 70
Message-ID: <aveplo$fsh$1@main.gmane.org>
References: <3E1A3B34.4060504@apache.org> <avea0v$kgh$1@main.gmane.org>
 <aveb6i$oha$1@main.gmane.org> <avecuj$uev$1@main.gmane.org>
 <3E1AD43F.1070702@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826
Sender: news <news@main.gmane.org>

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

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?

Ulrich


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>