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.
http://avalon.apache.org/merlin/api/org/apache/avalon/composition/ 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.
Rubbish! 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:
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.
Which is completely provided - i.e. functional blocks, block parameterization, etc. etc.
You have no such notion.
ROTFL 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
http://avalon.apache.org/merlin/meta/block/index.html:
<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.
Stephen.
-- Stefano.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
