avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [A4:Proposal][fortress] refactoring
Date Tue, 28 Jan 2003 04:03:40 GMT


Peter Royal wrote:

> On Monday, January 27, 2003, at 09:37  PM, Stephen McConnell wrote:
>
>>  Block <-- extends Appliance by (a) doing additional management of
>>     its implememntation (where block implementation referes to the
>>     components heirachy it is managing), and (b) publishes services
>>     established via the implementation as dynamic meta info - i.e.
>>     a block transforms itself into a normal component in that it
>>     exposed depedencies and services and can be applied as a
>>     solution when building other components.  Implemntation of (b)
>>     is currently in-progress.
>
>
> Could one extend a Block to provide a "layer" between its interface as 
> a component and the components that it manages? 


This is the direction I thinking about.  Basically I would to be able to 
plug in a block controller.  The controller would then be responsible 
for (a) the internal implementation - components and sub-containers, 
etc. - and the (b) service provision strategy.  This is currently 
handled as part of the block implementation but I would like to move to 
pluggable controllers once the block == component loop is finished.

>
> I like the layout (finally starting to pay more attention, head coming 
> up above the chaos). I'm concerned about the terminology of 
> 'Appliance' though. 


I really like it!

> Did you pick appliance in that a kitchen is made up of various 
> appliances?  (Appliance to me brings up images of microwaves, 
> dishwashers and refrigerators). 



Nope.

An appliance is something you "use" to achieve a result - it is a tool 
that helps you do something to something.  E.g. a washing machine washes 
clothes.  The thing of value is the clean clothes. The washing machine 
is tool that you plug into your infrastructure to help you do that task.

 * You plug an appliance into a containment environment.
 * The appliance cooks a component.
 * Different appliances can do similar this in different ways
   (e.g. the default implementation uses meta information as its
   strategy for cooking the component).  A block uses nested
   appliances to cook a container.

> While they are the (building-)blocks of a kitchen, I would think that 
> the relationship would be inverted, an appliance is a block. Just as 
> shelves, counters, cookbooks, utensils are also blocks, but not 
> appliances. 


I consider an appliance appropriate for micro-scale component 
management. On the other hand a block is macro. Keep in mind that I'm 
staying very close to the Cocoon functional requirements when I refer to 
block - which is different from the Phoenix term.  Phoenix notion of 
Block is a collection of classes + single meta info definition.  This is 
equivalent to the Assembly/Merlin definition of a component type.

>
> Could a merlin block be used directly as a phoenix block?
> -pete


Yes - providing Phoenix was updated to recognize that it is dealing with 
a dynamic component type.

In the case of block to component transformation, the container needs to 
recognize that the component type meta info is only the meta info about 
the construction of the blocks - its not the meta info of the block as a 
component.  To get the component model the container has instantiated 
the block (which is independent from instantiation of the blocks 
implementation) and then get the block-as-component-meta-model from the 
block.  Nice and clear isn't it! This means that the container needs to 
recognize the difference between a static component type and a dynamic 
component type.

Cheers, Steve.

-- 

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>


Mime
View raw message