Re: Requirements for implementing Cocoon Blocks

Ulrich Mayring wrote:

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


A couple of thoughts:

1. differnt users - different concerns - as a site adminstrator I'm 
interested in a management platform that provides me with a good 
overview of the system I'm assembling - as system manager I'm interested 
in runtime integrity, security, performance, monitoring, auditing.  As a 
consumer I'm interested in user level services that the platform makes 
available to me.  As a developer of a comonent I'm interested in the 
abiliity to off-load my container-side concerns.  As a container author 
I'm interested in a base platform that reduced my code to the business 
logic and deployment strategies.  

2. I'm also aware that I'm twisting your works around a bit here and 
substituting brands with areas of concern. Phoenix and Melin 
functionality overlap by about 60%.  Merlin Fortress overlap is sort of 
somewhere between 20 and 80% (doing very similar things for different 
usage criteria).  Cocoon Fortress overlap - my guess about 80% of 
present needs and 20% of future needs, and Melin Cocoon is sliding in at 
about 20% of immediate needs and 70% or future needs.  Throw in Phoenix 
Xxxx and your mainly looking at the management end-point.  Take away the 
brands and your left with a bunch of code and the need for a workplan.

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


Put it like this and I agree - it will not happen.

You cannot be all things to all people all of the time.

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


Zutt - but your comming in real close to runner-up for icky container 
names just behine the über-thing .... but I understand the jist of where 
your heading.

:-)

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


Sounds reasonable (throw into the sentence "transparent" somewhere close 
to "distributed" and I'll buy you a beer).

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


Yep.

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


I much more comfortable drawing pictures than doing the code stuff.

> It looks a bit like the wonder-container, am I right? 


Yes and no - the above already exists.

Now make the assumption that components are implicitly and transparently 
distributed and throw in meta to support this is a real distributed 
environment, get into the subject of cross-domain component 
collaboration and related coordination - and your taking about the 
something approaching a truley interesting.  Put on top of that 
community backing and something wonder-full.  But that's probably too 
biased on the direction I personally interested in. However, the 
end-game should be a container platform on which these objective become 
trivial plug-ins.

:-)

Cheers, Steve.


>
>
> Ulrich
>
>
>
> -- 
> To unsubscribe, e-mail:   
> <mailto:[email protected]>
> For additional commands, e-mail: 
> <mailto:[email protected]>
>
>
>

-- 

Stephen J. McConnell
mailto:[email protected]
http://www.osm.net