Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
Message-ID: <3E1AD43F.1070702@apache.org>
Date: Tue, 07 Jan 2003 14:21:03 +0100
From: Stephen McConnell <mcconnell@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.0) Gecko/20020530
MIME-Version: 1.0
To: Avalon Developers List <avalon-dev@jakarta.apache.org>
Subject: Re: Requirements for implementing Cocoon Blocks
References: <3E1A3B34.4060504@apache.org> <avea0v$kgh$1@main.gmane.org>
 <aveb6i$oha$1@main.gmane.org> <avecuj$uev$1@main.gmane.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit


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

:=)

>
>>> 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:
                             manages
                         |--------------|
                         V              |
  arbitrary_code --> component ---> container
                         ^              |
                         |is a          |
                         |--------------|

Cheers, Steve.

> cheers,
>
> Ulrich


-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net


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