Berin Loritsch wrote:
Stephen McConnell wrote:
I am NOT addressing meta-info or meta-data concerns
Which is itself problematic ;-)
No it isn't. If you recall I had two objections before we could release
Merlin.
Just as a matter of curiosity, whom are you representing under the term *we*?
One was beefing up AMTAGS, and the other has to do with the way context keys are assigned. That is what this thread is supposed to be about.
I am recognizing the URN approach as useful, and I am trying to put together
a solution that I think will help in the long term as well as the short
term regarding HOW it is useful.
Second, let me state what I am addressing:
1) There should be a correlation between namespaces and container extensions
Not necessarily - consider the following:
@avalon.entry key="urn:whoever:whatever" type="org.whoever.Widget"
The solution to this constraint is constrained by the meta-info declaration but it does not require or impose any constraint on the meta-data used to resolve the constraint. I.e. the declaration of some namespace in meta-info has zero impact on what is possible in meta-data land. If there is no correlation (other than the constraint) we have a classic contract/implementation separation. What I'm trying to say here is that the notion of a shared namespace ties problem to solution – but they are separate concerns - descriptors in meta-info define the problem (constraints) - directive in meta-data define the solution. Problem and solution should not be linked by namespace.
?!? I don't understand your point.
The point is that meta-info is about declaring the criteria. Your train of thought seems to be focussed on a context handling approach which can be dealt with on the container side in a standard or non-standard fashion without any implications concerning namespaces at the meta-info level. The namespace is a mechanism we can use on the implementation side of the equation to provide interesting solutions to how we deliver well-managed context.
If I understand what is written between the lines - you not keen on seeing a standard set of Avalon scoped context entries because this could be handled by a namespace linked context management subsystem - the benefits being that the Avalon namespace does not get polluted with unnecessary stuff. I don't have any problem with a generic namespace base context management model - in fact its something I've been thinking about for a while - but I do have a problem with attempting to define this now on the grounds that this will simplify the Avalon namespace question. This is backed by the fact that Phoenix and Merlin have near identical requirements for common set of five context entry keys. Think of these as the bootstrap set of keys - defined specifically to make life easier for container users.
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]
