Berin Loritsch wrote:
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.
I think this is not address the actual needs that are already identified. If we consider the James project, they has gone though a process of abstracting out context entry key lookups to a separate utility class as part of the process of establishing container neutrality. This extra code exist because we have not defining the very basic set of common context entries. I think this is well overdue. Getting in place a common core set of entries is real easy to do. I've already proposed the following:
urn:avalon.name urn:avalon.partition.name urn.avalon.home.dir urn:avalon.temp.dir urn:avalon.classloader
Are there really any problems mapping the above into any avalon container? I don’t think. I do know that the benefit to the end user will be immediate and tangible.
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.
The need for a core set of common context entries remains. Simply stating what the keys are that can be used consistently across containers does not conflict with different context management solutions provided by different containers. What is does do is set a minimal level of utility for a portable Avalon contextulizable interface.
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.
The existing spec for @avalon.context provides support for the declaration of context entry requirements independently of a containers context management solution. I don't definitely don’t think we should move this into the notion of extension - its well defined - meets immediate requirements - and is part of the core Avalon model.
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.
It’s a container problem - all the meta-info has to do is declare the constraint. Meta-data (out of scope for the moment) deals with the problem of building/declaring how to create special context content.
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.
Can you qualify this a bit more - I got the impression your hinting at something but I don’t know exactly what you’re hinting at. Personally I can't think of anything I would want to modify in the current @avalon.context and @avalon.type (and corresponding XML) relative to the existing implementation. Do you see any issues?
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.
Keep in mind that I think that an abstract extension framework at this stage is premature.
Does this proposal make sense, and be easy enough to implement?
Not really - I think its makes things unnecessarily complex. We have a simple system that works well I think we should focus on closing the configuration schema declaration as part of the type definition - finalize the attribute spec details - and that's it. W can safely evolve the meta-info platform because it’s based on a version schema identifier. I really think we should keep things as simple as possible - get things in place across containers - go though a learning curve - and with experience come back to the entire subject of meta-info extension.
Cheers, Steve.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
