@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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
