You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stephen McConnell <mc...@apache.org> on 2003/10/01 10:33:12 UTC
block perspectives
Geoff Howard wrote:
> Stephen McConnell wrote:
>
>> Geoff Howard wrote:
>>
>>> If you havn't read up on the blocks docs on the wiki lately (the
>>> last two weeks) you really should. Stefano has put a good series of
>>> pages up detailing the plan and the current implementation ideas.
>>
>>
>> Just a couple of observations -
>>
>> The usage of /BLOCK-INF may conflict with the Avalon Merlin container
>> /BLOCK-INF which is used to hold avalon block descriptors and related
>> configuration profiles. Usage of "block.xml" also conflicts with
>> block.xml used with the Merlin container which is not the same as
>> block.xml used with the Coocon context.
>
>
> As it seems you've been reading up on those docs can you give your
> perspective on where our needs differ from what the various Avalon
> options offer as they exist now and where they seem to be going in the
> near future?
Geoff:
Going back to early discussions on the notion of a block (RT-V2 from
memory) a common set of requirements could be asserted. These
requirements focus on the abstraction of Cocoon requirements to a more
general service management viewpoint relative to composite component
management.
* management of a running composite system
* functional and service modularization through packaging
* dynamic composition to create new functional units
Released Avalon facilities that collectively address all of the above
include the following packages/systems:
* Avalon Meta - a meta info model to describe a component contract
(service dependencies, context casting assumptions, context entry
dependencies, configuration schemas, parametirization and logging
assumptions) for a given component type - represented as a
serializable Type instance. http://avalon.apache.org/meta
* Avalon Composition - this is the meta-data model that describes
units of deployment and units of composition. A unit of deployment
associates a Type with a complete model describing how to deploy
and manage instances of the type. A unit of composition describes
the aggregation of a set of deployment units to form a virtual
deployment unit. As such, a unit of composition appears as a
unit of deployment. The composition model includes meta data
directives for classloader management, block composition by
reference, and service publication.
* Avalon Activation - the activation framework is the runtime system
within which serialized deployment and composition models are
established within the runtime environment (classloaders, devices,
ports, etc.). The activation framework provides support for
assembly of runtime managers (an Appliance that manages a deployment
model, and a Block that manages a containment model), the deployment
of managers, decommissioning, and potential recommissioning.
* Avalon Merlin - the Merlin platform is a container based on the
above packages and a number of Excalibur utilities that provides
support for the establishment of kernel level systems (logging,
jmx management, repository management, block archive (.bar)
installation, etc. The platform is designed for embedding within
different application scenarios. http://avalon.apache.org/merlin
In order to address the part of your question concerning where things
are going, I'll take a jump back to the original three bullet points I
referenced at the beginning and use this to throw some light on current
status and forward looking plans.
* management of a running composite system
What we have in place today is the ability to deploy and
decommission a kernel (i.e. an all of nothing solution). However, the
entire architecture, meta-model and runtime framework is designed to
support fine-grain management such that we will be able to redeploy
containment or deployment units anywhere within a hierarchy with
full consideration for implicit and explicit dependencies. This
will be exposed through JMX management points and will provide
support for custom component management points.
A second aspect of management concerns the federation of different
runtime kernels relative to a single management point. For example
a kernel running inside a web-app would register itself with a
management server. From the management server you see the set of
runtime kernel instance. Each kernel exposes a containment
hierarchy and the respective managers (Appliance and Block instances)
which in turn expose manageable component instances.
* functional and service modularization through packaging
The meta-info, meta-data, composition and activation framework
provides excellent support for the representation and micro-
level packaging of components at a system level. Complementing
this a repository framework that is structurally equivalent to
the Maven repository model (which provides some interesting
benefits when developing in the Maven environment). The
repository model is possibly the structural part of what is
refered to as a librarian in Cocoon.
Supporting repository management is the bar file. A bar file
(block archive) provides a packaging model that lets us associate
containment and deployment information into a single entity, along
with resources that must be packaged (for example - to meet
particular licensing requirements). Bar file structure mirrors
the structure of a repository for a particular group within a
repository. Current implementation provides support for bar
install. Bar execution is planned but requires some additional
work.
* dynamic composition to create new functional units
This subject is central to the composition, activation and Merlin
system. We can do dynamic creation of new service models via
composition of existing blocks. For example, each cornerstone
component is available in form that can be imported into a
composite definition. We have examples available of James as
a composite component, the recent release of the OpenIM instant
messaging platform, sharing many of the same components that
james uses - all using composition as the structural backbone
on which each is exposed as new dynamically created service.
However - there are some features of the Cocoon block vision that have
not been addressed at this time - and require more than a moments
thinking. The first of these is the notion of block inheritance. This
functionality is desirable from a service management perspective but
will not appear until the fundamentals are rock solid.
Aside from all of that - I have been lurking here off and on for several
months - and see overwhelming reasons for collaboration (and equally
overwhelming reasons why this could be a bad thing to do). In the short
terms there are items that need to be addressed over in Avalon land that
will priority in the short term. These include the incorporation of a
some additional functionality to complete the legacy Phoenix support
(Block listeners and JMX registration, and more comprehensive logging
support); work to bring the meta package, composition and activation
packages up to the point where we can handle ECM/Fortress components
with minimal transition overhead.
Once past the ECM/Fortress/Phoenix function support point - the roadmap
lays out a bunch of immediate priorities - management, federation,
distribution, and security.
Finally, I am aware that the above does not necessarily answer your
question concerning your needs - largely because its kind of difficult
to appreciate the needs (mainly a terminology background thing that
makes it hard work (for me) to unwind/translate concepts here into the
corresponding notions that I'm dealing with. Apologies for that and
hopefully this will provide at least a starting point.
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
Re: block perspectives
Posted by Stephen McConnell <mc...@apache.org>.
Stephen McConnell wrote:
> Stefano Mazzocchi wrote:
>
>>
>> 3) how open are you/avalon to changes to this DTD?
>
>
>
> Totally open.
>
> However, a better question is how reasonable is it to extend the
> deployment and composition object model instances. This implies
> implementation of readers and writers that capture domain specific
> (e.g. Cocoon value-added content) together with the underlying Avalon
> structures. Readers and writers currently include XML and serialized
> forms. In principal an extended form will be possible - and more to
> the point - will be required independently of Cocoon specific
> requirements simply to meet evolutionary needs in our object model.
>
> I.e. think in terms of meta-model class extension - as opposed to DTD
> proliferation.
Here are the links to the immutable serializable meta-data classes that
should be extended:
http://avalon.apache.org/merlin/api/org/apache/avalon/composition/data/ContainmentProfile.html
http://avalon.apache.org/merlin/api/org/apache/avalon/composition/data/DeploymentProfile.html
From here the next subject focusses on linking in a custom model
defintion that implements the following:
http://avalon.apache.org/merlin/api/org/apache/avalon/composition/model/ContainmentModel.html
http://avalon.apache.org/merlin/api/org/apache/avalon/composition/model/DeploymentModel.html
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
Re: block perspectives
Posted by Berin Loritsch <bl...@apache.org>.
Nicola Ken Barozzi wrote:
> Berin Loritsch wrote:
>
>>
>> That and how is the Cocoon block definition conflicting with Avalon
>> definition for blocks. I believe there is some conflict, and since
>> it seems that the Cocoon community doesn't want to have a two way
>> compatibility going on with Cocoon blocks,
>
>
> It's not that we don't want only, it's that it doesn't make sense to use
> a Cocoon block in a generic Avalon container.
>
> In fact the suggestions were to keep a common place but distinguish on
> DTD, so that future convergence could be easier. If you prefer the more
> clear-cut solution, I have no problem with it.
>
I believe Stefano made it pretty clear that he doesn't want to waste time
collaborating on the DTD or other block semantics. That's fine, but that
also means that you guys are pretty much operating with what should be
considered proprietary APIs/packaging requirements. To that end, you should
put proprietary information in a proprietary location.
Believe me, it is easier to merge when it is clear what is being merged.
When the lines are less clear, you tend to start assuming one side of the
equation already does something when it doesn't. Assumptions==bad. I would
rather make it painfully clear what is a Cocoon semantic and what is an
Avalon semantic so that when the time comes to merge, we can.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: block perspectives
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote:
> Nicola Ken Barozzi wrote:
>
>> Stefano Mazzocchi wrote:
>> ...
>>
>>> Because while deploying an avalon block in cocoon might make sense,
>>> deploying a cocoon block in merlin wouldn't make any sense at all.
>>
>> Exactly the point.
>>
>> Cocoon is not a generic container, it's a very specific container, and
>> our blocks can only work with Cocoon.
>>
>> What should instead be seen, is how to make Cocoon be based *on*
>> Fortress and be usable *in* Merlin.
>
> That and how is the Cocoon block definition conflicting with Avalon
> definition for blocks. I believe there is some conflict, and since
> it seems that the Cocoon community doesn't want to have a two way
> compatibility going on with Cocoon blocks,
It's not that we don't want only, it's that it doesn't make sense to use
a Cocoon block in a generic Avalon container.
If we use the same plug for electricity power and data signals, it
doesn't mean that we can plug them together and want them to work somehow.
> then it would be in everyone's
> best interest to make Cocoon blocks with Cocoon proprietary locations
> for meta-info. Change BLOCK-INF to COCOON-INF, and any block definition
> conflicts go away. That would be enough for now.
No problem with that.
In fact the suggestions were to keep a common place but distinguish on
DTD, so that future convergence could be easier. If you prefer the more
clear-cut solution, I have no problem with it.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: block perspectives
Posted by Berin Loritsch <bl...@apache.org>.
Nicola Ken Barozzi wrote:
> Stefano Mazzocchi wrote:
> ...
>
>> Because while deploying an avalon block in cocoon might make sense,
>> deploying a cocoon block in merlin wouldn't make any sense at all.
>
>
> Exactly the point.
>
> Cocoon is not a generic container, it's a very specific container, and
> our blocks can only work with Cocoon.
>
> What should instead be seen, is how to make Cocoon be based *on*
> Fortress and be usable *in* Merlin.
That and how is the Cocoon block definition conflicting with Avalon
definition for blocks. I believe there is some conflict, and since
it seems that the Cocoon community doesn't want to have a two way
compatibility going on with Cocoon blocks, then it would be in everyone's
best interest to make Cocoon blocks with Cocoon proprietary locations
for meta-info. Change BLOCK-INF to COCOON-INF, and any block definition
conflicts go away. That would be enough for now.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: block perspectives
Posted by Stefano Mazzocchi <st...@apache.org>.
On Thursday, Oct 2, 2003, at 13:42 Europe/Rome, Nicola Ken Barozzi
wrote:
> Stefano Mazzocchi wrote:
> ...
>> Because while deploying an avalon block in cocoon might make sense,
>> deploying a cocoon block in merlin wouldn't make any sense at all.
>
> Exactly the point.
>
> Cocoon is not a generic container, it's a very specific container, and
> our blocks can only work with Cocoon.
>
> What should instead be seen, is how to make Cocoon be based *on*
> Fortress and be usable *in* Merlin.
.. but that is a totally different concern and completely orthogonal to
our block design.
--
Stefano.
Re: block perspectives
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
...
> Because while deploying an avalon block in cocoon might make sense,
> deploying a cocoon block in merlin wouldn't make any sense at all.
Exactly the point.
Cocoon is not a generic container, it's a very specific container, and
our blocks can only work with Cocoon.
What should instead be seen, is how to make Cocoon be based *on*
Fortress and be usable *in* Merlin.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: block perspectives
Posted by Stephen McConnell <mc...@apache.org>.
Stefano:
My request to you to was "to go back and take another look". I was
specifically addressing the inconsistencies and errors in the claims
that you raised on this list. Given the level of gross inaccuracy
associated with your comments, I was compelled to correct the assertions
you were making.
I hope you understand.
As to the suggestion that I or Avalon are attempting to force decision
changes - I suggest you go back over the mail archives. I responded to
a request from Geoff Howard to put forward my thoughts "on where our
needs differ from what the various Avalon options offer as they exist
now and where they seem to be going in the near future?". I posted a
reply, attempting to outline my understanding of the common underlying
requirements based on (a) my contribution to early discussion on the
subject, (b) monitoring discussion here, and (c) reviewing documentation
on you site. Clearly the question prompted a reflection of Cocoon needs
relative to the aims and objectives with Avalon. I attempted to address
this question noting those areas that I considered as overlapping and
areas that I identified as outside of the area of concern relative to
Avalon priorities.
You chose to respond to my email with a series of negative emails
justifying "why Cocoon should ignore everyone else", and "the value of
trial and error", compounded with a technical assessment that was biased
in the extreme, in many cases completely faulted, and for the most part
missleading. Now you are making the assertion that I am attempting to
change established Cocoon designs. Nothing could be further from the truth.
Please note that I am simply responding to suggestions and requests from
members of the Cocoon community to take a more active role here in the
process of block development. Clearly that initiative has shown
immediate merit in the identification on conflicts between the Cocoon
design relative to working Avalon solutions. I hope and remain confident
that the broader Cocoon community will continue to remain open and
receptive to ideas and experience that other communities have to offer.
Stephen.
Stefano Mazzocchi wrote:
>
> On Thursday, Oct 2, 2003, at 16:59 Europe/Rome, Stephen McConnell wrote:
>
>> Please - go back and take another look.
>
>
> Stephen,
>
> while I thank you for your interest in creating synergies, I am not
> interested in modifying the cocoon block design at this point and I
> don't see value in doing so.
>
> If our design contains bugs or problems, I would like to this
> community to find them, this community to learn them and think about
> them.
>
> Help from others, as usual, is and still will be very appreciated, but
> you are not giving us any help. You are suggesting that we take a look
> at your design, instead of coming up with our own.... but we have
> spent months in designing this thing and we are almost done and ready
> to start implementing.
>
> [I hope the GT will finish the design phase]
>
> I personally took a look at your design for curiosity and for respect.
> I didn't see anything that would help us.
>
> I'm biased, I know. But you are as well.
>
> Let's agree to disagree and move on, so that I don't waste anymore of
> your time making you roll on the floor laughing.
>
> --
> Stefano.
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
Re: block perspectives
Posted by Stefano Mazzocchi <st...@apache.org>.
On Thursday, Oct 2, 2003, at 16:59 Europe/Rome, Stephen McConnell wrote:
> Please - go back and take another look.
Stephen,
while I thank you for your interest in creating synergies, I am not
interested in modifying the cocoon block design at this point and I
don't see value in doing so.
If our design contains bugs or problems, I would like to this community
to find them, this community to learn them and think about them.
Help from others, as usual, is and still will be very appreciated, but
you are not giving us any help. You are suggesting that we take a look
at your design, instead of coming up with our own.... but we have spent
months in designing this thing and we are almost done and ready to
start implementing.
[I hope the GT will finish the design phase]
I personally took a look at your design for curiosity and for respect.
I didn't see anything that would help us.
I'm biased, I know. But you are as well.
Let's agree to disagree and move on, so that I don't waste anymore of
your time making you roll on the floor laughing.
--
Stefano.
Re: block perspectives
Posted by Stephen McConnell <mc...@apache.org>.
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:mcconnell@apache.org
Re: block perspectives
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
Re: block perspectives
Posted by Stephen McConnell <mc...@apache.org>.
Stefano Mazzocchi wrote:
>
> On Wednesday, Oct 1, 2003, at 16:22 Europe/Rome, Stephen McConnell wrote:
>
>> Stefano Mazzocchi wrote:
>>
>>>
>>> So, a few questions:
>>>
>>> 1) where is the DTD of your block.xml?
>>
>>
>>
>> There is no DTD due to the fact that we wanted to include user
>> configuration directly in component directives.
>
>
> ok
>
>> Instead we aim to apply schema validation via tools - but this is
>> work in progress. In the meantime there is the site documentation
>> that provides a reasonably complete picture of the block.xml
>> datastructure.
>>
>> http://avalon.apache.org/merlin/meta/block/index.html
>
>
> that's good enough.
>
> Reading thru it:
>
> 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.
>
> 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.
> 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
> 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?
>
> 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.
A component declares depedecies on 0..n services. Each dependency
defines a service type. A component can also publish 0..n services that
it provides. The container is responsible for ensuring that a
deployment scenario is valid and complete. This process is handled
entirely by the container. Where multiple candidates exist for a
particular association, the container can apply a selection filtering
based on assembly directives associated with the *consumer*.
>
>
> 6) markup versioning and referencing are done thru DOCTYPE instead of
> namespace declaration.
>
>>> 2) is that block.xml an avalon-wide thing or just merlin-related?
>>> [means: is that shared with Phoenix?]
>>
>>
>>
>> The block.xml defines a model relative to the Avalon Composition
>> package (the meta model definition). This package is based on the
>> Avalon Meta package which includes legacy support for the Phoenix
>> container. Avalon Meta reads in Phoenix <blockinfo> descriptors and
>> transparently converts these to Avalon Meta Type descriptors. As
>> such, the composition package has no need to know about anything
>> specific to Phoenix as it is dependent on a Type descriptor which is
>> container independent.
>
>
> Ok, Merlin only but phoenix compatible, right?
Not Merlin only. The composition package is a seperate package, as it
the meta data package. Collectively the meta, composition and
activation packages represent seperate facilities that provide support
to the problems of general component and service management. You will
find lots of test cases demonstrating different aspects - all of which
are independent of Merlin. Today these packages are used in ant tasks,
plugins and the Merlin container.
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
Re: block perspectives
Posted by Stefano Mazzocchi <st...@apache.org>.
On Wednesday, Oct 1, 2003, at 16:22 Europe/Rome, Stephen McConnell
wrote:
> Stefano Mazzocchi wrote:
>
>>
>> So, a few questions:
>>
>> 1) where is the DTD of your block.xml?
>
>
> There is no DTD due to the fact that we wanted to include user
> configuration directly in component directives.
ok
> Instead we aim to apply schema validation via tools - but this is
> work in progress. In the meantime there is the site documentation
> that provides a reasonably complete picture of the block.xml
> datastructure.
>
> http://avalon.apache.org/merlin/meta/block/index.html
that's good enough.
Reading thru it:
1) lack of polymorphic dependencies.
2) lack of block metadata for human consumption.
3) lack of extension capabilities.
4) lack of block-level parameter definitions.
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]
6) markup versioning and referencing are done thru DOCTYPE instead of
namespace declaration.
>> 2) is that block.xml an avalon-wide thing or just merlin-related?
>> [means: is that shared with Phoenix?]
>
>
> The block.xml defines a model relative to the Avalon Composition
> package (the meta model definition). This package is based on the
> Avalon Meta package which includes legacy support for the Phoenix
> container. Avalon Meta reads in Phoenix <blockinfo> descriptors and
> transparently converts these to Avalon Meta Type descriptors. As such,
> the composition package has no need to know about anything specific to
> Phoenix as it is dependent on a Type descriptor which is container
> independent.
Ok, Merlin only but phoenix compatible, right?
>> 3) how open are you/avalon to changes to this DTD?
>
> Totally open.
>
> However, a better question is how reasonable is it to extend the
> deployment and composition object model instances.
Exactly. From what I listed above, the block composition model would
have to be entirely redesigned to fit our needs. [which our current
design already meets perfectly, I should note]
> This implies implementation of readers and writers that capture domain
> specific (e.g. Cocoon value-added content) together with the
> underlying Avalon structures. Readers and writers currently include
> XML and serialized forms. In principal an extended form will be
> possible - and more to the point - will be required independently of
> Cocoon specific requirements simply to meet evolutionary needs in our
> object model.
The Merlin block model lacks polymorphic dependencies. This is not a
little cocoon-specific change, Stephen, this is the entire foundation
of the concept!!
> I.e. think in terms of meta-model class extension - as opposed to DTD
> proliferation.
Sorry but I can't parse this.
>> At the end, if collaboration is not possible, it would still be
>> possible, for containers, to react on namespaces to understand the
>> different semantics of the markup used (ah, btw, merin's block.xml
>> don't use namespaces, that is generally a good future-friendly
>> practice)
>
> This is a example of where expertise here can have a positive impact
> on the core system development over on Avalon.
Simply write
<container xmlns="http://apache.org/avalon/merlin/block/1.0">
...
</container>
and the cocoon block deployer will be able (would the need emerge) to
understand this is an avalon block and not a cocoon block, and deploy
accordingly.
[this could be done thru DOCTYPE reaction as well, but namespaces are a
much cleaner way to do this]
IMO, that's the simplest solution that can possible work for both
worlds.
Because while deploying an avalon block in cocoon might make sense,
deploying a cocoon block in merlin wouldn't make any sense at all.
--
Stefano.
Re: block perspectives
Posted by Stephen McConnell <mc...@apache.org>.
Stefano Mazzocchi wrote:
>
> So, a few questions:
>
> 1) where is the DTD of your block.xml?
There is no DTD due to the fact that we wanted to include user
configuration directly in component directives. Instead we aim to apply
schema validation via tools - but this is work in progress. In the
meantime there is the site documentation that provides a reasonably
complete picture of the block.xml datastructure.
http://avalon.apache.org/merlin/meta/block/index.html
>
> 2) is that block.xml an avalon-wide thing or just merlin-related?
> [means: is that shared with Phoenix?]
The block.xml defines a model relative to the Avalon Composition package
(the meta model definition). This package is based on the Avalon Meta
package which includes legacy support for the Phoenix container. Avalon
Meta reads in Phoenix <blockinfo> descriptors and transparently converts
these to Avalon Meta Type descriptors. As such, the composition package
has no need to know about anything specific to Phoenix as it is
dependent on a Type descriptor which is container independent.
>
> 3) how open are you/avalon to changes to this DTD?
Totally open.
However, a better question is how reasonable is it to extend the
deployment and composition object model instances. This implies
implementation of readers and writers that capture domain specific (e.g.
Cocoon value-added content) together with the underlying Avalon
structures. Readers and writers currently include XML and serialized
forms. In principal an extended form will be possible - and more to the
point - will be required independently of Cocoon specific requirements
simply to meet evolutionary needs in our object model.
I.e. think in terms of meta-model class extension - as opposed to DTD
proliferation.
>
>
> At the end, if collaboration is not possible, it would still be
> possible, for containers, to react on namespaces to understand the
> different semantics of the markup used (ah, btw, merin's block.xml
> don't use namespaces, that is generally a good future-friendly practice)
This is a example of where expertise here can have a positive impact on
the core system development over on Avalon.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
Re: block perspectives
Posted by Stefano Mazzocchi <st...@apache.org>.
On Wednesday, Oct 1, 2003, at 10:33 Europe/Rome, Stephen McConnell
wrote:
[big snip]
> Aside from all of that - I have been lurking here off and on for
> several months - and see overwhelming reasons for collaboration (and
> equally overwhelming reasons why this could be a bad thing to do).
I want cocoon 2.2 to implement cocoon blocks and I want it finished
soon, less than 6 months (including the block librarian and all that).
This doesn't give me much time to spend on discussing details with
other projects.
I've looked at merlin/meta and I don't think how this can help us in
the development (yeah, well, maybe steal some classes here and there,
but the actual implementation is simply too different)
I believe it's much better if cocoon and avalon keep their focus (no
matter how big the functional overlap is: the goal overlap is very
small and the community overlap (in terms of active committment) is
null) and keep working independently.
In the future, when both system are implemented, we'll see how things
go and potential refactoring might take place.
In order to allow this, the only thing where I do see potential
collaboration now is the block.xml descriptor schema... because we
could well change /BLOCK-INF/ to /COB-INF/ but that would make the two
systems diverge forever.
So, a few questions:
1) where is the DTD of your block.xml?
2) is that block.xml an avalon-wide thing or just merlin-related?
[means: is that shared with Phoenix?]
3) how open are you/avalon to changes to this DTD?
At the end, if collaboration is not possible, it would still be
possible, for containers, to react on namespaces to understand the
different semantics of the markup used (ah, btw, merin's block.xml
don't use namespaces, that is generally a good future-friendly practice)
> --
Stefano.