Since we are well underway with the AMTAGS proposal, I wanted to start my thoughts on context entries. Currently we have two basic approaches for context keys:
* Using URNs * Using opaque strings
Truth be told, there is no real advantage to using one over the other from a purely technical standpoint. The only tangible advantage comes from the management perspective. In fact, the URN makes for much easier scoping of context entries. A Universal Resource Name helps us understand that the resource belongs to a namespace, and has a unique name within that namespace. Whether that resource lives locally on the hard drive or on a remote server does not matter, we can use the same name to access it. That is its strength.
A Resource has specific properties. A resource accessible from a specific name will always be the same exact resource. That means if the resource is text, the return value will be text. If the resource is a URL, the value will always be a URL when accessed by that name. We can use two URNs to refer to the same logical thing, but if the logical thing is represented differently, they are separate resources. For example, a File representing the application home directory and a URL representing the same thing are distinct resources.
That said, I like the strength of URNs for management purposes. I think that Merlin is on the right track with using URNs internally. I believe that the @avalon.entry tag provides for the use of an alias, much the same way as the @avalon.dependency does the same thing when we refer to a type.
A URN is composed of three elements:
* The text "urn:" which identifies a string as a URN. * The namespace which precedes the following ":" and comes after the above text * The actual name of the resource
Examples would be:
urn:avalon:name -- Avalon component name urn:application:home/file -- Application home as a File
I think we need to be very strict on what we allow in a URN namespace. For example things that help components with management such as the component name or logger category can go in the Avalon namespace. All other things like application home/partition home/etc. should go in their own namespaces. That way we can specify them as we specify namespaces. I believe this approach will provide the most flexible and sustainable method of managing the context functionality of Avalon.
In fact we can identify this as an area that we need to provide for with container extensions. A container extension needs to provide the context entries that it provides from its namespace. If the context entry is not volatile, then its value should be able to be overridden in the assembly stage--but that is a matter for another discussion.
I also think that by employing this general solution, we can avoid a bunch of unnecessary conflict between those trying to keep the Avalon namespace small and those trying to enable a set of functionality.
Phoenix and Fortress need to reconcile their commonalities and possibly define some context entries for the application namespace. That way we can specify common namespaces for extensions like the "lifecycle" extension or the "management" extension.
Does this proposal make sense, and be easy enough to implement?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
