Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <3F7C2245.6090800@apache.org>
Date: Thu, 02 Oct 2003 15:04:05 +0200
From: Stephen McConnell <mcconnell@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: block perspectives
References: <18B735D9-F4C3-11D7-AD24-000393D2CB02@apache.org>
In-Reply-To: <18B735D9-F4C3-11D7-AD24-000393D2CB02@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


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