Meta: Where to begin?

[Berin Loritsch <bl...@apache.org>]

Where does Meta begin?  There are the TypeBuilders the XMLTypeBuilder,
etc.  However, how do we verify the component and set it up?  How do
we know which implementations to load in?  We declare dependencies
on interfaces not implementations (at least we should), so if we have
a config passed in to our container how do we interpret it?

Is there a default?  If not, then I have to figure out how to do it
all myself--which begs the question of how I can get completely away
from the RoleManager (as a way of short-circuiting the role vs.
full interface name).

Anyway, pointing me in the right direction would help.

Also, what attributes are you using to determine the lifestyle of
a Merlin component with Meta?  If at all possible I would like to
make it standard.


"They that give up essential liberty to obtain a little temporary safety
 deserve neither liberty nor safety."
                - Benjamin Franklin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Meta: Where to begin?

[Stephen McConnell <mc...@apache.org>]

Berin Loritsch wrote:

>Where does Meta begin?  
>

It begins with the class.
It excalates with an .xinfo (or a .xtype).
How does a container find this information?

   * by following an avalon convention - i.e. agreement across the board 
that some <cl;assname>.<extesnsion> is the standard meachism trhough 
which we load this suff

Ok, so we have a .xinfo or whatever loaded .... how do we interprit this?

  * a generic loader looks at the root element
  * is it a <type> or is it <blockinfo>, or is it somethig else
  * based on the root element, take care of it and build an internal 
meta-info model
  * requires that each implementation knows about the other models and 
variations

This is what the excalibur/meta packge does.
Other solutions are not a generouse.

  * given a object model of a type you can populate a type manager with 
types
  * given a type manger you can start managing type deployment profiles

>There are the TypeBuilders the XMLTypeBuilder,
>etc.  However, how do we verify the component and set it up?  
>

Verification at this stage is reasonably easy - your basically 
validating that the meta-info model is consitent with the computation 
interfaces exposed by the component implemetnation class.

>How do we know which implementations to load in?  
>

Today - you track the Avalon list and you make you deliver an 
implemetation that deals with the entire know word.  In our case, the 
entire known world is the Type DTD, the BlockInfo DTD and the 
containerkit DTD.  The excalibur/meta package deals with all of these in 
order to use these as input to a single consistent meta-info model.

>We declare dependencies
>on interfaces not implementations (at least we should), so if we have
>a config passed in to our container how do we interpret it?
>  
>

No we are moving into meta-data land.
The configuration passed to a container is going to container 
information about the instantiation criteria to apply to a compoent 
type.  We have allready established a componet type - semi independelty 
of the DTD we had to work with.  So as this point we are no longer 
concerned with DTDs or meta-info choices - because the meta-mata model 
is structurally bound to one meta-info model.  

>Is there a default?  If not, then I have to figure out how to do it
>all myself--which begs the question of how I can get completely away
>from the RoleManager (as a way of short-circuiting the role vs.
>full interface name).
>

There is no default.  Migration from RoleManager to a meta-data data API 
involves assesment of the options available:

  * use containerkit meta-info and meta-data
  * use excalibur meta-info and build your own meta data
  * leverage the Merlin meta data solution and we work on evolving this 
if needed

Your choices are to some degree constrined by the fact that the 
excalibur/meta package is the only meta solution that provides support 
for the declaration of declaration of extension capability and 
depedency.  According to all of the info to-date - this status isn't 
going to change anytime soon.  Getting the role manager resoved is 
something I'm interested in because this gives me an oppotuntiy to 
explore some "distributed" publishing opportunities related to Cocoon..
 

>Anyway, pointing me in the right direction would help.
>
>Also, what attributes are you using to determine the lifestyle of
>a Merlin component with Meta?  If at all possible I would like to
>make it standard.
>  
>

http://jakata.apache.org/avalon/component/attributes.html

This contains the details of the meta-info attributes related to lifestyle.

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>