Re: Component Discovery and Resolution

Leo Simons wrote:

> Berin Loritsch wrote:
>
>>> @avalon:info.name <name>
>>> @avalon:info.version <version>
>>> @avalon:info.attribute <key> <valaue>
>>>
>>> Where avalon:info.name equates to Fortress/ECM shorthand name?
>>>
>>> One other thing, in the background work I've been doing I'm using 
>>> the URN convention of <domain>:<key> - i.e. 
>>> "avalon:something.whatever.etc".
>>
>
> note: these are not URNs. URNS are prefixed with "urn:", don't contain 
> qutoes, etc etc. ie stuff like:
>
>    <excluded> ::= octets 1-32 (1-20 hex) | "\" | """ | "&" | "<"
>                   | ">" | "[" | "]" | "^" | "`" | "{" | "|" | "}" | "~"
>                   | octets 127-255 (7F-FF hex)
> (from the RFC)
>
> not saying they should be urns (we had that discussion already), just 
> you shouldn't dub them urn if they're not.


Read my text again - I suggested using the URN *convention* of 
<domain>:<key> enabling the seperation of the dictionary (identified by 
the domain) from the feature (identified by the key) within the dictionary.

>> Yes, but we need a dictionary of keys that our users can build upon.
>> I would like to get the minimal set done now--which ignores validation
>> arbitrary attributes and version info.  Just enough to tell the
>> container what is available.
>
>
> +1
>
>> You see, merlin and phoenix seem to have their own set of naming
>> conventions.  I would really prefer if our users don't have to do
>> a global replace on all the attribute names when they upgrad from
>> Fortress to Merlin or Merlin to Phoenix.
>
>
> +1
>
>> Keep in mind that Phoenix has been doing the attributes the longest,
>> so I would tend toward using their conventions.
>
>
> +1
>
> I would add that that goes not only for the way attributes are marked 
> in the sources, but also for any other files you generate from them 
> and where those end up. I don't want to end up with
>
<snip/>

>
> Specifically, if it is possible to not use services.list in favor of 
> using the blah.xconf setup phoenix uses and accomplish the same thing, 
> I would strongly prefer that. I am guessing the ng/ stuff in fortress 
> accomplishes exactly or some of that (though I haven't looked at it).
>
> In general, if it is at all possible and sensible to use the phoenix 
> metageneration tasks, the phoenix tag conventions, the phoenix 
> configuration file locations, etc etc, then that is the right thing to 
> do for fortress, merlin, etc. It will make life so much easier when 
> implementing any kind of "spearhead", and it makes applications (not 
> just components) cross-container to a larger extent.


There is an alternative way of looking at this.

Currently we have a number of different ways of holding meta information 
and meta data.

  * ECM/Fortress role files (combines meta-info and
    meta-data) + marker interfaces supporting a demand
    driven deployment model.

  * Phoenix with meta-info under <classname>.xinfo files
    and meta-data at the application level using
    config.xml and assembly.xml supporting a single level
    structured composition model.

  * Merlin with <classname>.xinfo for meta-info,
    <classname>.xconfig for type specific configuration defaults,
    <classname>.xprofile for type specific meta-data deployment
    defaults, and block.xml for composition and isolation.


One approach is to consider different sources as potential inputs, and 
from this establish a common meta-info and meta-data model that is 
derived from these different source.  The meta-info can be common across 
all containers on a per-component basis.  That's probably the easiest 
bit (we already have the ability to read Phoenix meta-info into Merlin 
in the form of a Type - the same thing is readily achievable in 
Fortress).  The meta-data is where most of the differences are.  Both 
Phoenix and Fortress scope meta-data at an application level whereas 
Merlin captures a lot of this information in the form of defaults at the 
class level then enable a very significant simplification of application 
level content.

The meta package over in sandbox (as a example) attempts to bridge the 
extremes (ECM/Fortress/Merlin/Phoneix). This is taking a practical 
approach of leveraging a common meta-info enabling creation of model 
instances using Phoenix <blockinfo> or Merlin <type> or Fortress roles.  
Using this approach we get to a point where the next step is meta data 
encompassing directives and defaults. Moving on from their we can 
address things like (for example) a configuration repository as 
container-side service - isolating the mechanisms used for configuration 
registration, updating, retrival, etc.  In other words, building from 
the ground up the infrastructure for interoperability and comminality.

Cheers, Steve.


-- 

Stephen J. McConnell
mailto:[email protected]
http://www.osm.net