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).
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.
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.
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.
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.
http://avalon.apache.org/merlin/api/org/apache/avalon/composition/ model/package-summary.html
Extension == "inheritance" as in "one block extending another block".
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.
For us, the concept of block inheritance is very useful.
4) lack of block-level parameter definitions
Given the scope of parameterization covered in the following data types:
http://avalon.apache.org/merlin/api/org/apache/avalon/composition/ 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.
You have no such notion.
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
http://avalon.apache.org/merlin/meta/block/index.html:
<component name="application"
class="tutorial.application.Application" activation="startup">
</component>"name" is a hint. Potentially, two blocks in the same address space might provide the same hints. This creates conflicts. Hints/names, IMO, should not be given by the provider, but by the user.
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.
-- Stefano.
