avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject Re: The need for 'hints'
Date Wed, 19 Jun 2002 09:39:06 GMT


Stefano Mazzocchi wrote:

>Peter Donald wrote:
>  
>
>>At 08:15 PM 6/17/2002 +0200, you wrote:
>>    
>>
>>>>The role name is just that - an arbitrary name. ie Stephen tends to use
>>>>names such as "socket-factory", "ssl-socket-factory" etc which are quite
>>>>valid (even if I dislike that they no follow defacto standard). Each role
>>>>name designates a component that satisfies certain constraints. In
>>>>ECM/Cocoon land there is only one constraint (ie class/type of returned
>>>>component) hence the rolename maps to class returned. In some containers
>>>>there can be other constraints.
>>>>        
>>>>
>>>Ok, this is probably a context that I'm misssing, can you elaborate more
>>>on this? It would be helpful to understand your insights.
>>>      
>>>
>>Okay I will try ;)
>>    
>>
>
>Thanks, this makes it a lot clearer. Please, see my comments intermixed.
>
>  
>
>>Perhaps it is better to describe it in terms of a hypothetical container
>>that could be created once I finish the new metainfo stuff. Consider a
>>component X. Associated with that component is some metainfo and assuming
>>it is a similar format to Phoenixs Blockinfo assume it has a section such as
>>
>><component>
>>...
>>   <dependencies>
>>     <dependency>
>>       <role>my-transformer</role>
>>       <service classname="org.apache.cocoon.api.Transformer"/>
>>       <attribute name="type" value="xslt"/>
>>     </dependency>
>>   </dependencies>
>>...
>></component>
>>
>>This saids that X has a dependency on a component that implements interface
>>org.apache.cocoon.api.Transformer, is of type "xslt" and is accessed from
>>ComponentManager using the key "my-transformer". Note I have intentionally
>>left "type=xslt" undefined as it is a container specific concept.
>>(Alternatively you may do something like "handles-dtd=..." or whatever).
>>
>><service/> + <attribute/>s == constraints on dependency
>><role/> == key used to lookup component
>>
>>So all the container needs to do is lookup a component with the key
>>"my-transformer" and the correct component is returned.
>>    
>>
>
>Cocoon needs a 2-d lookup space, this is not going to change in the
>future. The above doesn't give it to me unless I namespace the key:
>
> - 'generator:file'
> - 'org.apache.cocoon.generating.Generator/file'
> - ???
>

Stefano:

Image that you have to live with the rule that assembly infromation may 
not be supplied to a container as a method argument.   Imagine that this 
is a really strinct rule - that is enforced by generic containers. 
 There are two conclusions you can draw from this:

1.  that it is a components responsibility to publish assembly criteria 
and functional constraints formally
2.  that criteria that connot be expressed at a type level (i.e. in meta 
declarations) is criteria that is application specific in which case the 
component should be requesting a component capabable of servicing the 
application level semantics


>
>then, what do I gain from A5?
>

Let me rephrase the question to "what do I gain from the seperation of 
concerns of assembly for application context" and the answer to that is 
portability of components across containers.

> 
>  
>
>>The process of determining the correct component is essentially what we
>>have been terming "assembly" and is currently container specific (and will
>>continue to be so in all likelihood).
>>    
>>
>
>Of course.
> 
>  
>
>>* Phoenix requires that the user explicitly assemble component and make
>>sure all components have their components mapped correctly etc.
>>    
>>
>
>Ok.
>
>  
>
>>* Merlin will auotmatically assemble the application. ie For each
>>dependency it will look for potential providers among other components. If
>>there is only one potential provider it will use that. If there is more
>>than one potential provider then it will select one based on some heuristic
>>(it uses a "policy" (aka "hint") attribute).
>>    
>>
>
>Ok, great. So, what's wrong with
>
> lookup(role, policy)
>
>?
>  
>

The most significant thing that is wrong about this is that it places 
infromation about assembly into the code of the component.  Keep in mind 
that the lookup operation is only concerned about assembly.  As soon as 
something goes into the lookup operation that is not opaque and managed 
within the componet namespace, your eliminating the potential for 
validation and assembly tools that are dependent on the expression of 
this information at a type level.  For example, I can assemble a 
component type graph without instantiating a single component.  I can 
validate that assembly without instantiating a single component.  But if 
you put structure into the role argument, or if you supply a policy 
argument, your introducing criteria that must be really formall defined 
(so that generic containers can undersand it in an interoperable 
fashion), and you eliminating the potential for pre-instantiation 
validation (i.e. deferring validation until the lookup request hits the 
component manager).

>  
>
>>* ECM does not separate out assembly and development stages. Effectively
>>you hardwire the assembly information into the components when you supply
>>interface name + "hint"
>>    
>>
>
>This is the hack I'm referring to when I see ROLE + "/hint" and I
>totally agree with you that this is bad.
>
>*STILL* I need a way to suggest the container a specific lookup policy
>(strategy, methodology, philosophy, call it as you like! but we *NEED*
>that information separate from the role)
>
>Look: because Phoenix doesn't need it, it doesn't mean that the rest of
>the world doesn't need it.
>
>Moreover, you are explicitly stating that other containers (Merlin) need
>that, so what's the damn problem with a 2-d lookup mechanism?
>  
>

If a think called a lookup policy comes in through a lookup operation, 
what should Merlin do with this ?
How would it effect Merlin's composition strategy ?

>  
>
>>* Fortress is currently similar to ECM but Leo plans to fix it so that it
>>is possible to to assemble component outside code (whether he chooses
>>Merlin or Fortresses strategy I am not sure but I believe  Merlins is more
>>approriate for Cocoon).
>>
>>So if Leo chooses to go the Merlin-esque route then there will no changes
>>to current sitemap format unless you want to explicitly declare a mapping
>>rather than allowing the container to auotmatically manage it.
>>
>>What will be changed is the presence of per component descriptors. You may
>>say that these are a PITA to maintain (and they are!) so what I plan to do
>>is create an XDoclet task to autogenerate them. 
>>    
>>
>
>hmmm,
>
>  
>
>>So what you will need to do
>>is add in javadoc markup to your component so that they look like the
>>following.
>>
>>/**
>>  * @avalon.component lifestyle="threadsafe"
>>  */
>>class MyComponent
>>{
>>   /**
>>    * @avalon.dependency role="my-transformer" service="Transformer"
>>type="xslt"
>>    */
>>   void compose(ComponentManager cm)
>>   {
>>     m_myDependency = (Transformer)cm.lookup( "my-transformer" );
>>   }
>>}
>>
>>Note the above would produce a descriptorsimilar to the one I outlined
>>above. However in cases where you follow the convention and the lookup key
>>is the same as the interface name you can get away with even less markup so
>>that it just looks like
>>
>>   /**
>>    * @avalon.dependency service="Transformer" type="xslt"
>>    */
>>   void compose(ComponentManager cm)
>>   {
>>     m_myDependency = (Transformer)cm.lookup( Transformer.ROLE );
>>   }
>>
>>An architecture like the above is soooooo much easier to maintain than the
>>current ECM which has a global namespace and treats the ComponentManager as
>>a Container. It will also allow much more flexability in future and is more
>>maintainable.
>>    
>>
>
>Know what? I tend to agree with this. The need for all those
>class="org.apache.*" stuff in XML files bothered me a lot. Placing them
>in a XDoclet type wrapper makes a lot of sense, even if it won't be easy
>to make the cocoon-dev community buy that.
> 
>  
>
>>Given an architecture like this there is no longer any need for a second
>>hint parameter in ComponentManager.lookup() method. 
>>    
>>
>
>But I can't see this. Sorry, please, be patient.
>

What sort of information do you want to supply via lookup ?
How does this information relate to existing component types and 
instantiated component instances managed by the container?
 From you answer I'll try to explain how this can work, and what the 
implications are relative to the container and the component.

>
>  
>
>>It would also allow all
>>the containers to share components which is currently not possible due to
>>differences in way we specify metadata.
>>
>>Does that make it any clearer?
>>    
>>
>
>Yes, I like what I see conceptually, but I don't see, from what I
>understood, why you feel that a 2-d lookup space (role,policy) is bad.
>  
>

Its puts assembly semantics into code and that eliminates the potential 
for validation before execution.  Elimination of this step eliminates 
the potential for real management (i.e. suite type management).

>  
>
>>The key points are;
>>
>>* separating the lookup key for dependency from set of constraints
>>associated with dependency
>>    
>>
>
>Absolutely, I agree they should be decoupled, this is exactly why I
>liked the 2-d lookup approach where one dimension connected with the
>dependency and another one to the constraints associated with the
>dependency.
>

But its in the code!!
This information does not need respide in the code.
This information can be used in a maner which is orthogonal to the 
component.
This information is part of the structural contract and must be declared 
in order for delivery of components.

>
>  
>
>>* simplifying interface from user perspective and making it harder to abuse
>>the
>>* separating out separate stages/views (ie assembler vs develoepr view).
>>* easing product evolution
>>    
>>
>
>These are highly subjective and I won't question them.
>
>Like I said, I like what I see, but I fail to see why a 2-d lookup space
>is a bad thing, even with the context you give me.
>  
>

Because its in the code - its in the code - its in the code!

:-)

Cheers, Steve.

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




--
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