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