cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <>
Subject Re: block perspectives
Date Thu, 02 Oct 2003 14:59:32 GMT

Stefano Mazzocchi wrote:

> On Thursday, Oct 2, 2003, at 15:04 Europe/Rome, Stephen McConnell wrote:
>>>  1) lack of polymorphic dependencies
>> Dependencies are adaptive to the implementation strategy.
>> A block author does not need to declare any dependencies as these 
>> are  implicity established based on service dependencies declared by  
>> components that make up the block implementation.
>> When a block is deployed - the container wires the block up service  
>> published by other components and/or blocks.
>> That process will result in the resolution of set of dependencies 
>> that  are a function of the component dependencies that constitute 
>> the block  implementation.  This approach means that there is no 
>> requirement for  dependency declaration at the level of a block.
> You are assuming that blocks just include components and are not  
> functional components "per se". This is insufficient for our needs  
> (more below). 

There is a missunderstanding here.  A block publishes the services that 
it provides and contains an implementation model based on components.  
As such these blocks are totally functional units.

>>>  2) lack of block metadata for human consumption.
>> Correct.  The block matadata focusses on the definition of an  
>> implementation strategy. This is balanced by meta-info at the  
>> component type level that supports association of human readable 
>> data  across all aspects of the component defintion.  As mention 
>> before -  the block implementation presents as a dynamic component - 
>> and as  such, human readable information would be exposed as meta info.
> Again, you make the assumption that a block is just a container of  
> components. 

Again - you ignoring the point that a block is a fully functional unit.


> For us, a cocoon block is a first-class functional unit, in short, a  
> "component" for cocoon webapps. What you are doing at the component  
> level, we need to do it at the block level.
> This is why we need explicit dependencies (althought dependencies can  
> be on block behaviors, thus behave polymorphically), explicit 
> metadata  and so on. 

Sorry - I don't understand the issue.  As far as I can see the Avalon 
model provides full support for dependencies on services.  These 
dependencies are derived from the computation model (i.e. the 
implementation). I.e. the dependencies are there - accessible - 
resolvable - and full associated with metadata.

> You assumption that this is not needed becase "it should happen at  
> another level" just doesn't work for us since while for you every  
> service is an avalon component, for us that's clearly not the case.

The assumption is incorrect.  A service is an interface published by a 
block.  A block provides the implementation strategy.  Different types 
of blocks can provide different implementation strategies.  Its even 
possible for different types of blocks to use different meta data - 
providing that the resulting meta model interfaces are respected.  This 
allows a high level of variation in the implementation approach.  For 
example - a ORB can be considered as object providing a set of services 
based on a application specific configuration.  In effect this is a 
different component model to the classic Avalon model.  Alternative 
models can coexist because the meta model is presented as a set of 
interfaces and meta info and meta data structures are presented as an 
extendable object model.

>>>  3) lack of extension capabilities.
>> We disagree here.  The entire meta-data model has been created with  
>> extension and interoperation in mind.  In fact if you take a look at  
>> the composition package apis, you will find comprehense set of model  
>> interfaces and an implementation approach which assumes that  
>> meta-models form different environments are working together as part  
>> of composite solutions.
>> model/package-summary.html
> Extension == "inheritance" as in "one block extending another block". 

Inheritance is one approach to extension.
And, yes - the notion of block inheritance is not provided in our 
current release (for the reasons I already noted).

> You have no notion of one block inheriting another block. And this 
> is,  again, due to the assumption that blocks provide no functionality 
> per  se, thus the concept of "inheritance' has no meaning. 

Blocks have function - please go back and take a proper look.

> For us, the concept of block inheritance is very useful. 

I understand that.  What I don't understand is why you don;t see Avalon 
blocks as functional objects?  They are - how else could they function 
as components?

>>>  4) lack of block-level parameter definitions
>> Given the scope of parameterization covered in the following data  
>> types:
>> data/package-summary.html
>> What aspects of parameterization do you think are lacking?
> Again, a block has its own functional capabilities. so it requires 
> its  own properties to be configured at deploy time. We explicitly 
> indicate  these properties so that at deployment time they can be 
> asked by the  deployment manager to the user doing the deployment. 

Which is completely provided - i.e. functional blocks, block 
parameterization, etc. etc.

> You have no such notion.

Please - go back and take another look.

>>>  5) definition of the component/service hint at the provider level
>>> [I believe this is bad, the provider should specify the component 
>>> ID,  the compontent requirer should specify how it is hinted in its 
>>> local  domain of use]
>> There is no notion of "hint" by providers.
> from your example in
> <component name="application"
>         class="tutorial.application.Application" activation="startup">
>      </component>
> "name" is a hint. 

It is not a hint - it is a name.

> Potentially, two blocks in the same address space  might provide the 
> same hints. This creates conflicts. 

A name is a unique with it enclosing containment context.
There are no clonflicts.

> Hints/names, IMO,  should not be given by the provider, but by the user. 

They are not hints.
The conclusion simply is invalid.

> In our design, the provider states
>  <component class="mypackage.MyComponent"/>
> and the consumer states
>  <uses component="mypackage.MyComponent" name="mycomponent"/>
> so, different consumers might use different hints for the same  
> component, or the same hints for different components but no 
> collission  will happen.

Did you notice that the Avalon model does not require the declaration of 
<uses/> style statements?  Maybe not as you seem to be assuming that the 
component name is a "hint".  Roll back for a moment.  The entire 
assembly process is automatic - you don't need to declare usage 
statements - that's the job of the container.  The container looks at 
the component meta model and does the entire process of wirring together 
a deployment solution, and ensures that the deployment solution is valid 
before a single component instantiation occurs. The model also provide 
means through which a consumer can override automatic assembly by 
declaring a named component as the provider.


> -- 
> Stefano.


Stephen J. McConnell

View raw message