Re: Component Discovery and Resolution

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.

> 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

ECM
---
roles.conf
...

Fortress
--------
fortress.conf
fortress.xlog
fortress.xpool
services.list
myblock.service
...

Phoenix
-------
kernel.xml
blocks.xml
myblock.xconf
...

Merlin
------
merlin.conf
assembly.conf
assembly.roles
blocks.conf
...

Merlin2
-------
...

Spearhead
---------
...

etc etc.

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.

cheers,

- Leo, having some doubts whether this is a smart idea for fortress 1.0