Re: Requirements for implementing Cocoon Blocks

[Ulrich Mayring]

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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>