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