avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject Re: Component Metadata and Metainfo model
Date Fri, 05 Jul 2002 08:35:02 GMT


Leo Simons wrote:

>>>Never going to use an interface again for this. If you remember back 
>>>about 1 1/2 years ago we separated out interface and implementations for 
>>>the meta classes. It sucked hugely.
>>>      
>>>
>>I don't know if it sucked or it spit :-) , but what is the need of 
>>having an interface versus implementation?
>>Will there be many implementations, one for each container? Why is it 
>>needed?
>>    
>>
>
>It seems there may indeed be multiple implementations. FA, Stephen has
>already extended metadata (think it is called "profile" or something).
>  
>

I've extended ComponentMetaData (to Profile) and ComponetInfo (to Type). 
 Having interfaces around these two is desirable - in fact I'm playing 
around with this at the moment.  Under the containerkit varient the 
ComponentMetaData requires the client to supply fully prepared 
DependecyMetaData instances - and that a really painfull constraint. 
 Life becomes dramtically easier if I can incrementally at dependecy 
meta data as a I navigate containers.  I'm not saying this justifies an 
interface - but it cetainly makes life easier if I use an alternative 
implemetation that I can change to meet requirements.

Just a note - I hate the MetaThis, MetaThat frequence.  It's really 
confusing for users.
What I'm doing locally is:

    Type <--- was ComponentInfo
    Profile <-- was ComponentMetaData
    Association <-- was DependecyMetaData

Clarity in naming is important.

>The main reason I chose to use interfaces in the setup is that
>interfaces (at least at avalon) imply contracts rather than
>implementations, and I feel what we should be discussing is contracts
>instead of implementation details.
>
>  
>
>>Since this is just a "structure" (no "real" methods), it seems that 
>>using interfaces is not needed.
>>    
>>
>
>yup.
>  
>

I agree with exception on the ComponentInfo class and ComponentMetaData 
class.  The need to specialize ComponentInfo may dissapear but I also 
have in the back of my mind the meta model extensions OSM has produced 
for collaborative components using DPML (Digital Product Modelling 
Language).  As far as ComponentMetaData in concerned - this is a issue I 
have with the constructor constraints - final and imuutable if fine for 
Phoenix - it suck for Merlin (too static).

>  
>
>>Yes, why are they here?
>>What would they be used for?
>>I don't understand.
>>    
>>
>
>simple enough: to pass to the component. You can see this as a
>formalization of phoenix its ApplicationEntry (if that still exists....)
>
>  
>
>>I think we should standardize on some common stuff to describe 
>>components, ie
>>- version
>>- role
>>- description
>>
>>Where is doesn't make sense, a default version or description is used.
>>    
>>
>
>yup. There is some stuff in containerkit already to do this. Basically,
>there is
>
>- role
>- service description
>	[version, classname, attributes]
>- attributes
>
>  
>
>>>-1
>>>Selection criterion are context sensitive and can be relegated to a 
>>>particular container implementation.
>>>      
>>>
>>Selection cretarion are "context sensitive"? You mean that selection
>>is done depending on what you have to select?
>>
>>I don't think so, assembly semantics *has* to be the same if we want 
>>things to work between containers.
>>    
>>
>
>Nah, as soon as you start discussing "possible alternatives" the
>selection between different alternatives can be container specific (I
>*think* that's what he ment, anyway).
>  
>

Just for reference - Merlin 2 enables service selection by user supplied 
plug-ins which can be declared in the dependency attributes, or 
alternatively, can be supplied at a container level applying to all 
services of the type.  Meta defined selection overrides container wide 
selection overrides default selection.

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