avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [proposal] avalon 5 ComponentManager interface
Date Mon, 17 Jun 2002 14:43:45 GMT


Stephen McConnell wrote:
> 
> 
> Nicola Ken Barozzi wrote:
> 
>>
>> Stephen McConnell wrote:
>>
>>>
>>>
>>> Nicola Ken Barozzi wrote:
>>>
>>>>
>>>> Stephen McConnell wrote:
>>>>
>>>>>
>>>>>
>>>>> Peter Donald wrote:
>>>>>
>>>>>> At 11:16 AM 6/17/2002 +0200, you wrote:
>>>>>>
>>>>>>> role+hint is *not* a simple way of declaring role="base+hint"
>>>>>>>
>>>>>>> Role: what do do
>>>>>>> Hint: *how* to do it
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I would not say that. I would say
>>>>>>
>>>>>> Role: arbitrary name indicating a dependency
>>>>>> Hint: metainfo associated with dependency indicating a possible 
>>>>>> policy for selecting from candidate providers. 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ++++++++++++++++++++++++++++++++++++++++++++1
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Tell me how to use flat roles in Cocoon.
>>>> Tell me.
>>>>
>>> Nikolas:
>>>
>>> As you know, my knowledge of Cocoon is very limited (its basically 
>>> derived from what you have told me about Cocoon usage of ECM).  
>>> However, I'll try to compose a response :-)
>>>
>>> Cocoon creates a sitemap - the sitemap declares info the about the 
>>> "interfaces" and the "preferences" that will result in components 
>>> performing a transitioning of an XML doucment to something else.  A 
>>> Cocoon application can look at this sitemap (which can be viewed as a 
>>> set of execution constraints) and validate that the suite of 
>>> components are available to meet thos constraints - where 
>>> availability means (a) I have a component implemetation that is 
>>> capable of providing the service interface, and optionally (b) I have 
>>> a componet implementation that is capable of providing the interface 
>>> relative to the implementation preferences.
>>
>>
>>
>> This is *not* optional.
>> Hints in Cocoon are *not* optional. 
> 
> 
> 
> I have to confess that I am now totally confussed about the term "hint". 
> Based on my english language knowlege - a hint is something that can 
> provide a optional indicator of direction - a hint does not imply 
> anything absolute.  However, in the Cocoon context the word "hint"is 
> being used to describe a policy to a container that is required by a 
> client.

This is exactly what I think.

It may be wrong, but you got my point.

>> You cannot assume that an XSLT transformer can be replaced by a 
>> ReplaceAllTagsWithCoolTagTransformer do the same thing.
>> They do *not*, even if they have the *same* interface.
>>
>> >   So instead of Coocoon hitting something like ECM with a
>>
>>> bunch of interface names and tags, Cocoon first of all hits a kernel 
>>> with a configuration of services to build, the kernel validates that 
>>> everything that is needed is available as far as it can, registers 
>>> sitemap directives (role/tag info) against identifiable component 
>>> implementation instances - then at runtime, when the role/tag info is 
>>> supplied the kernal is soiply passing back the identifiable component 
>>> instance from its internal map.
>>>
>>> Does that make sence?
>>> If not - what are the pieces that are missing?
>>
>>
>>
>> You are saying the same thing, only saying that hints must be defined 
>> at startup.
>> "registers sitemap directives (role/tag info)" clearly says that we 
>> *do* have role+hint.
>>
>> Defining them at startup or at runtime makes no difference, 
> 
> 
> 
> Agreed.
> 
>> they are still there, and it makes sense to keep them separate, since 
>> they have different meanings: 
> 
> 
> 
> I agree that these are better keep seperate. However - I'm now feeling 
> very certain that there is a general mixup of terms (at least I know I'm 
> cofussed on the subject of roles and hints).

;-) yeah

> Imaging we have:
> 
>   client-context - information supplied by a client that *may* be
>     used by a container to influence its response - client context
>     *may* be ignored by a container
> 
>   client-policy - information supplied by a client that directly
>     impacts container behavior and represents part of the client/container
>     contract - client policy *must* be understood by the container
>     if the container is going to service the client request
> 
> Let's ignore client-context for a moment.
> 
> The primary concern is where policy information is derived.  A component 
> implementation could declare policy support at a type level or at an 
> instance level.  Type level policy can be declared in meta-info and can 
> be managed by a container.  Instance level policy (e.g. taking a 
> component type, instantiating it, and differentiating the instance 
> through conguration/context/service state has the potential to establish 
> the instance as a component capable of supporting a particular policy. 
> This type of instance level policy can be used by a container to 
> differentiate when selecting a component to return to a client.  Both 
> type and instance policy can be declared in the context of a particular 
> application - type level is generic and would be usable across 
> containers - instance level is getting container specific because you 
> have to introduce some knowlege into the container about the 
> establishment of identifiable instances.

Good explanation, yes.

I think that a sub-role is general enough to be regarded as not being 
container specific.

Call that subrole, constraint2, or whatever, but what you say is correct.

>>
>> 1) Role: what to do: interface (dependency) 
> 
> Can be declared in the type meta-info (so interface name can be 
> expressed as a opaque key).

I still think that opaque kwys should be interfaces, or the contract 
remains too loose.
But I don't have *that* strong feelings on it.

>> 2) Sub-Role: how to do it: behaviour on environment (dependency) 
> 
> 
> Resolution of the interface via the meta-infomation already provides us 
> with access to a dependecy declaration.  This dependecy declaration can 
> include policy - i.e. specific constraints that consumer component 
> requires to be fulfilled by a container when making an instance 
> selection.  Policy declared inside a dependecy declaration implies that 
> the consumer component has knowlege about the type of supplier 
> component. This implies a family of components and basically the 
> introduction of policy handlers types that are recognized by all 
> containers. 
> If the policy is something that is unrelated to a consumer component 
> dependency declaration (i.e. not-declared in dependecy meta-info), then, 
> and only then, you are introducing additional semantics into the process 
> of a component lookup.  In this scenario, a lookup( String opaque, 
> Constraint  constraint ) would be required in order for the container to 
> differentiate between the identification of candidate supply components 
> (using the opaque string), and selection of a single component from the 
> candidates using the supplied constraint).

Yes, yes, yes! Hey, can we say that the message got across? :-D

>> 3) Hint: suggestion of who should do it: implementation (not mandatory)
>>
>> The name "hint" used by ECM is misleading, since Cocoon hints are not 
>> something that can be ignored.
>>
> Which basically means (presumption mode on) that your doing sufficient 
> setup in Cocoon to make sure that the ECM hint resolution is always 
> sucessfully resolving your supplied policy directive (constraint).

Yes.

> Am I getting closer ?

I think you've got what I mean :-D

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message