avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Requirements for implementing Cocoon Blocks
Date Tue, 07 Jan 2003 13:21:03 GMT

Ulrich Mayring wrote:

> Leo Simons wrote:
>> Ulrich Mayring wrote:
>> Probably. But the idea is to do a proper extraction of that container 
>> framework and do as much work as possible within the avalon scope. 
>> Peeps are talking of building "profiles" on top of such a framework 
>> to handle more specific needs, with easy tweaking of those profiles 
>> for your application-specific needs. SoC, really.
> If it's possible I'm all for it. So far Cocoon is a major customer, 
> maybe there are some others, I don't know. But once you have a number 
> of major customers like Cocoon my guess is you won't be able to make 
> all of them happy with a über-container. But, as I said, I'd love to 
> be proven wrong :)

OK - I ready to take you up on that :-)

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

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?


>>> So, to me the interesting question is: what do we give up if we give 
>>> up on a block-concept and instead rely only on a component concept?
>> are you referring to cocoon or in general? In general application 
>> decomposition, we often find logical partitions of the application 
>> into components, and then logical partition of those components into 
>> subcomponents, up to a level where a subsubsubcomponent becomes to 
>> small as to warrant the component management overhead.
> I was talking about application development in general.

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

>> arbitrary partitioning is an application-neutral concern. I'm 
>> guessing a cocoon block model would be application-specific, with a 
>> large part addressable by application-neutral stuff. We need to 
>> figure out how avalon can provide the application-neutral stuff, and 
>> also make it easy for cocoon to put the application-specific stuff on 
>> top of that.
> What do you mean by arbitrary partitioning? There already is arbitrary 
> partitioning by way of Avalon components. How much more arbitrary do 
> you want to become? For example, do you want to do something like this:
> arbitrary_code --> Java class
> Java classes --> component
> components --> block
> blocks --> application
> Where you have four different ways of partitioning? That would seem 
> not very arbitrary - the developer has to adhere to four different 
> contracts and what if he needs a fifth partition?
> Arbitrary partitioning to me would mean something like this:
> arbitrary_code --> component
> components --> component
> While this is more elegant, because it has only one contract and the 
> developer can be real arbitrary, it does not seem very useful to me. 

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

Cheers, Steve.

> cheers,
> Ulrich


Stephen J. McConnell

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