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:41:40 GMT


Leo Simons wrote:

>On Fri, 2002-07-05 at 09:29, Peter Donald wrote:
>  
>
>>At 09:17 AM 7/5/2002 +0200, you 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.
>>>>        
>>>>
>>>Can't say that I do...could you provide a keyword or archive link?
>>>      
>>>
>>Nope. Have a look through phoenixs CVS history it should be there. 
>>Previously I tried to write a generic container infrastructure but failed 
>>miserably due to overspecification of everything. The results of this are 
>>scattered through history of jakarta-avalon and 
>>jakarta-avalon-excalibur/all CVSes under the "container" package.
>>    
>>
>
>rings a bell. What was it again, camelot 'n friends?
>
>At that point, I think we removed it because the only 'real' container
>we had was phoenix (ECM wasn't really viewed as such) so it made no
>sense to separate any of it out.
>
>Now, we have quite a few containers (and everyone now has an idea of
>what it is and does) and some more experience. I'd say the situation
>thus has improved to a point where more people get what we're doing, and
>on the other hand we're off worse because there is no portability.
>
>Hence trying once again, no?
>
>  
>
>> > >{
>>    
>>
>>>>>        DependencyMetaData[] getDependencyData();
>>>>>        Logger getLogger();
>>>>>          
>>>>>
>>>>-1
>>>>This should go into component entry not metadata as it is tied to a
>>>>particular instance, not a profile.
>>>>        
>>>>
>>>in my definitions of metadata and metainfo, metadata is indeed tied to a
>>>particular instance, or at least to a group of functionally equivalent
>>>instances (ie a pool). It is more or less the same as a component entry.
>>>
>>>The metainfo is the profile.
>>>      
>>>
>>Your definitions differ from mine then. Metainfo is meta information about 
>>type. (MOF Level 0 MetaData). It has 0 information about profile prototype 
>>or anything similar.
>>    
>>
>
>MOF?
>

Meta Object Facilty - an OMG specification that is basically the core 
spec of the Java Meta stuff (at the least the Java stuff can be 
considered as a mapping from Java to the MOF).  Great reading - but take 
a could of Asprin first.

>
>  
>
>>MetaData is the component profile.
>>
>>Entry is the runtime information about component. ie Actual Logger, 
>>Context, instance (or pool), dependency instance references etc.
>>
>>My model does not say anything about component profile prototype. I was not 
>>going to address it as I wanted to see the outcome of work that Peter is 
>>doing on phoenix and Stephen is doing on Merlin.
>>
>>The model also does not offer a COnfiguration or Parameters Schema yet 
>>(again I am waiting to see experimentation on Phoenix).
>>    
>>
>
>ah. These definitions aren't very clear from looking at the current
>containerkit :/
>  
>

Naming, naming naming.
It matters.
:-)

>I take it I should look at kernel.ComponentEntry....that's pretty devoid
>of any explanation or contract atm...I take it the idea is to expand on
>it once we know a bit more?
>

Its an container internal reosurce - should not effect the MetaInfo, 
MetaModel discussion.

>
>anyways, I sort-of get the direction headed and I'll start with throwing
>in a bit of (javadoc) documentation in the general direction of
>containerkit.
>  
>

In the meantime I'm going to play around with a fork of containerkit 
(metainfo, metadata, infobuilder and verifier) so I can actually get 
into classes and do what I need to do.

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