You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Simons <le...@apache.org> on 2002/11/27 12:04:29 UTC
[vote] context key string format
Hi all,
It will be beneficial to both container developers and container users
if identical functionality placed into the context can be found using
identical context key formats.
It will also be beneficial to have namespace separation in the context
keys to avoid clashes where the functionality is not the same but the
context key is.
This was discussed back in august, and recently brought up again. Noel
suggested we adopt the IETF standard RFC 2141 by reference. I think it
is a good idea and I've seen no evidence other people don't.
Therefore, I propose we incorporate RFC 2141 by reference as the
preferred way of formatting context keys.
here's my +1.
If no-one objects, I will add a documentation snippet to the coding
standards and find or write a utility class for making it easy to
properly parse RFC 2141-formatted strings (probably
org.apache.avalon.framework.context.ContextUtil).
Comments
--------
First of, I said "preferred way". I don't think there is a need to make
it a requirement that context keys are formatted this way; that would
also cause backward compatibility problems.
RFC 2141 is a specification of the format of URNs, universal resource
identifiers. A urn consists of a case insensitive prefix, "urn:",
followed by a case-insensitive alphanumeric namespace (domain) part, a
":", and then an opaque key which can contain most characters (I believe
? # and one or two others are excempt). Refer to
http://www.ietf.org/rfc/rfc2141.txt for details. Example keys could be
urn:avalon-info:work.directory
urn:avalon-merlin:blahaahaahat
urn:avalon-brazil:current.time
urn:avalon-phoenix:home.directory
cheers,
- Leo Simons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [vote] context key string format
Posted by Stephen McConnell <mc...@apache.org>.
+1
Leo Simons wrote:
>Hi all,
>
>It will be beneficial to both container developers and container users
>if identical functionality placed into the context can be found using
>identical context key formats.
>
>It will also be beneficial to have namespace separation in the context
>keys to avoid clashes where the functionality is not the same but the
>context key is.
>
>This was discussed back in august, and recently brought up again. Noel
>suggested we adopt the IETF standard RFC 2141 by reference. I think it
>is a good idea and I've seen no evidence other people don't.
>
>Therefore, I propose we incorporate RFC 2141 by reference as the
>preferred way of formatting context keys.
>
>here's my +1.
>
>If no-one objects, I will add a documentation snippet to the coding
>standards and find or write a utility class for making it easy to
>properly parse RFC 2141-formatted strings (probably
>org.apache.avalon.framework.context.ContextUtil).
>
>
>Comments
>--------
>First of, I said "preferred way". I don't think there is a need to make
>it a requirement that context keys are formatted this way; that would
>also cause backward compatibility problems.
>
>RFC 2141 is a specification of the format of URNs, universal resource
>identifiers. A urn consists of a case insensitive prefix, "urn:",
>followed by a case-insensitive alphanumeric namespace (domain) part, a
>":", and then an opaque key which can contain most characters (I believe
>? # and one or two others are excempt). Refer to
>http://www.ietf.org/rfc/rfc2141.txt for details. Example keys could be
>
>urn:avalon-info:work.directory
>urn:avalon-merlin:blahaahaahat
>urn:avalon-brazil:current.time
>urn:avalon-phoenix:home.directory
>
>cheers,
>
>- Leo Simons
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [vote] context key string format
Posted by Stephen McConnell <mc...@apache.org>.
Peter Donald wrote:
>On Tue, 3 Dec 2002 05:13, Noel J. Bergman wrote:
>
>
>>I saw Pete's comments. I, personally, don't agree with him and I didn't
>>see him veto the approach, hence my summary.
>>
>>
>
>If need be I will ;)
>
>
>
>>By parsable, I mean in accordance with the RFC into the urn:NID:NSS parts.
>>The NID gets you to the namespace, which should be useful for scalable
>>container context and with component registration, the NSS is handled by
>>the namespace and can certainly be a simple key. In other words, the
>>contract for the NSS is provided by the namespace definition, and can be as
>>restrictive as desired.
>>
>>
>
>We have spent a lot of time removing the need for parsed lookup keys for
>ServiceManager/ComponentManager. We have moved to a set of recomended
>conventions (postfix with "/" then a discriminator) but they are just that -
>recomendations. They are not enforced or required in many containers.
>
>
What we currently pass to both Context and CM/SM are unparsed strings.
The postfix convention of "/" is a ECM artifact reflecting dynamic
resolution and the necessity to parse. Hense a conflict at the framework
level and divergent semantics. If the ECM solution had chosen to use a
URN structure, then life today would be a lot easier with respect to
handling mixed static and dynamic usage.
Something to consider about the URN convention is that it does not
impact any existing implementation - you still do things equivalent to
map.get( key ). However, if things don't work out, you have a much more
structured namespace from within which to potentially resolve request,
log information, report etc. Secondly, it well overdue move to getting
some rigerouse specification into the Avalon framework.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [vote] context key string format
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 3 Dec 2002 10:10, Noel J. Bergman wrote:
> And with respect to new development, I don't believe that I imagined other
> folks supporting the idea of using RFC 2141, and using the NID and NSS to
> address sub-contexts, and to provide the flexibility for the sub-contexts
> to determine whether or not they want to parse the NSS or just use it as a
> lookup key.
>
> The ability to federate multiple service providers within a context is a
> simple, elegant and powerful approach. The overhead is minimal, the
> approach is consistent.
Federated context contributors for data based entrys in context is fine. There
does not need to be any parsing of lookup keys to do such stuff though. They
are independent concerns.
> OK, so then you do agree with "separating", just not "parsing"? Fine.
> Then don't define any of the provided contexts to parse their NSS.
It is a convention for the lookup key and not a requirement for type of
resource. If you want we could expand the idea of a entry to have one more
component "intention" which may be parsed (or may not).
So for example our Entrys would look like
<entry key="foo" type="java.io.File" intention="avalon:base-dir"/>
then code looks like
public void contextualize( final Context context )
{
m_baseDir = (File)context.get( "foo" );
}
> > Prefixing everything with "urn:" is unecessary noise.
>
> The prefix is part of RFC 2141.
Andthat does not stop iut being unecessary noise.
--
Cheers,
Peter Donald
*---------------------------------------------------------*
| Contrary to popular belief, UNIX is user-friendly. It |
| just happens to be selective on who it makes friendship |
| with. |
| - Richard Cook |
*---------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [vote] context key string format
Posted by "Noel J. Bergman" <no...@devtech.com>.
> We have spent a lot of time removing the need for parsed lookup keys for
> ServiceManager/ComponentManager.
Why? What issues did you have?
And with respect to new development, I don't believe that I imagined other
folks supporting the idea of using RFC 2141, and using the NID and NSS to
address sub-contexts, and to provide the flexibility for the sub-contexts to
determine whether or not they want to parse the NSS or just use it as a
lookup key.
The ability to federate multiple service providers within a context is a
simple, elegant and powerful approach. The overhead is minimal, the
approach is consistent.
> Separating out namespace from local name using a ":" is already accepted
as a
> convention I believe.
OK, so then you do agree with "separating", just not "parsing"? Fine. Then
don't define any of the provided contexts to parse their NSS.
> Prefixing everything with "urn:" is unecessary noise.
The prefix is part of RFC 2141. Why? "Uniform Resource Names (URNs) are
intended to serve as persistent, location-independent, resource identifiers
and are designed to make it easy to map other namespaces (which share the
properties of URNs) into URN-space. Therefore, the URN syntax provides a
means to encode character data in a form that can be sent in existing
protocols, transcribed on most keyboards, etc."
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [vote] context key string format
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 3 Dec 2002 05:13, Noel J. Bergman wrote:
> I saw Pete's comments. I, personally, don't agree with him and I didn't
> see him veto the approach, hence my summary.
If need be I will ;)
> By parsable, I mean in accordance with the RFC into the urn:NID:NSS parts.
> The NID gets you to the namespace, which should be useful for scalable
> container context and with component registration, the NSS is handled by
> the namespace and can certainly be a simple key. In other words, the
> contract for the NSS is provided by the namespace definition, and can be as
> restrictive as desired.
We have spent a lot of time removing the need for parsed lookup keys for
ServiceManager/ComponentManager. We have moved to a set of recomended
conventions (postfix with "/" then a discriminator) but they are just that -
recomendations. They are not enforced or required in many containers.
Separating out namespace from local name using a ":" is already accepted as a
convention I believe. Prefixing everything with "urn:" is unecessary noise.
Theres no problem if people choose to not follow the convention but we will
support them better if they do.
--
Cheers,
Peter Donald
----------------------------------------
Why does everyone always overgeneralize?
----------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [vote] context key string format
Posted by "Noel J. Bergman" <no...@devtech.com>.
Berin,
I have no problem defering the issue until other issues come into focus. I
was responding to Leo Sutic's question about the status of the vote. If he
wants to call off the vote for another time, that's fine.
> We might need a new mechanism to provide pluggable context types.
> In that case, each context type would determine if it uses the
> proposed URNs or not.
I agree with the predicate, but I don't see the conclusion as being the case
at all. But we can discuss it later.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [vote] context key string format
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Noel J. Bergman [mailto:noel@devtech.com]
>
> Leo,
>
> I saw Pete's comments. I, personally, don't agree with him
> and I didn't see
> him veto the approach, hence my summary.
Noel, there are other usage issues that come into play with
the Context object. I think our time will be best served
by determining if we are focusing on Avalon 5 contracts for
future development or an Avalon 4.2 (same as current framework
interfaces but with additional contracts).
The bottom line is that the whole Context concept might come
under fire--esp. since it is highly domain specific. We might
need a new mechanism to provide pluggable context types. In
that case, each context type would determine if it uses the
proposed URNs or not.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [vote] context key string format
Posted by "Noel J. Bergman" <no...@devtech.com>.
Leo,
I saw Pete's comments. I, personally, don't agree with him and I didn't see
him veto the approach, hence my summary.
By parsable, I mean in accordance with the RFC into the urn:NID:NSS parts.
The NID gets you to the namespace, which should be useful for scalable
container context and with component registration, the NSS is handled by the
namespace and can certainly be a simple key. In other words, the contract
for the NSS is provided by the namespace definition, and can be as
restrictive as desired.
RFC 2141 keys provide a standard that allows any namespace to treat it as an
opaque key, and allows for application flexibilty within a namespace if it
so requires, which means that it ought to accommodate future requirements
without change.
By the way, SOAP uses RFC 2141.
--- Noel
-----Original Message-----
From: Leo Simons [mailto:leosimons@apache.org]
Sent: Monday, December 02, 2002 4:21
To: Avalon Developers List
Subject: RE: [vote] context key string format
Pete said:
"I don't think it is useful to add in this class as keys are opaque
strings (much like keys to services). The keys are thus unparsed
entitys. I also think that prefixing with "urn" does not add value
because all entrys will presumably do this."
some context key concerns:
- they are unambiguous (ie unique)
- they are well-known
- they are documented
- they are as human readable as possible
- there is not other contract besides being an instance of
java.lang.String
the first goals are supportive of URNs, while the last one means that it
might actually be best to leave that undocumented because we don't want
to imply contracts that are not there.
IOW, the visual clue is good, the "parsable" is not. The context key is
not to be parsed in any way; ie the only thing to do with a context key
is do equals() on it.
hence my doubts :D
cheers,
- Leo
On Mon, 2002-12-02 at 10:02, Noel J. Bergman wrote:
> Leo,
>
> Looked like 3 +1 and no vetoes from my count earlier.
>
> Having domains should prove useful with the scalable server. The "urn:"
> prefix is part of the RFC and provides both a visual clue as a well as
> parsable information.
>
> --- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [vote] context key string format
Posted by Leo Simons <le...@apache.org>.
Pete said:
"I don't think it is useful to add in this class as keys are opaque
strings (much like keys to services). The keys are thus unparsed
entitys. I also think that prefixing with "urn" does not add value
because all entrys will presumably do this."
some context key concerns:
- they are unambiguous (ie unique)
- they are well-known
- they are documented
- they are as human readable as possible
- there is not other contract besides being an instance of
java.lang.String
the first goals are supportive of URNs, while the last one means that it
might actually be best to leave that undocumented because we don't want
to imply contracts that are not there.
IOW, the visual clue is good, the "parsable" is not. The context key is
not to be parsed in any way; ie the only thing to do with a context key
is do equals() on it.
hence my doubts :D
cheers,
- Leo
On Mon, 2002-12-02 at 10:02, Noel J. Bergman wrote:
> Leo,
>
> Looked like 3 +1 and no vetoes from my count earlier.
>
> Having domains should prove useful with the scalable server. The "urn:"
> prefix is part of the RFC and provides both a visual clue as a well as
> parsable information.
>
> --- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [vote] context key string format
Posted by Paul Hammant <pa...@yahoo.com>.
Please lets hold off until some of us can read all our email on this subject.
- Paul
--- Stephen McConnell <mc...@apache.org> wrote: >
>
> Noel J. Bergman wrote:
>
> >Leo,
> >
> >Looked like 3 +1 and no vetoes from my count earlier.
> >
> >Having domains should prove useful with the scalable server. The "urn:"
> >prefix is part of the RFC and provides both a visual clue as a well as
> >parsable information.
> >
>
> +1
>
> Lets do it.
>
> S.
>
> --
>
> Stephen J. McConnell
>
> OSM SARL
> digital products for a global economy
> mailto:mcconnell@osm.net
> http://www.osm.net
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [vote] context key string format
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>Leo,
>
>Looked like 3 +1 and no vetoes from my count earlier.
>
>Having domains should prove useful with the scalable server. The "urn:"
>prefix is part of the RFC and provides both a visual clue as a well as
>parsable information.
>
+1
Lets do it.
S.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [vote] context key string format
Posted by "Noel J. Bergman" <no...@devtech.com>.
Leo,
Looked like 3 +1 and no vetoes from my count earlier.
Having domains should prove useful with the scalable server. The "urn:"
prefix is part of the RFC and provides both a visual clue as a well as
parsable information.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [vote] context key string format
Posted by Leo Simons <le...@apache.org>.
this is still pending....add a recommendation or not? I'm not so sure
anymore ;D
cheers,
- Leo
On Wed, 2002-11-27 at 12:17, Peter Donald wrote:
> On Wed, 27 Nov 2002 22:04, Leo Simons wrote:
> > If no-one objects, I will add a documentation snippet to the coding
> > standards and find or write a utility class for making it easy to
> > properly parse RFC 2141-formatted strings (probably
> > org.apache.avalon.framework.context.ContextUtil).
>
> I don't think it is useful to add in this class as keys are opaque strings
> (much like keys to services). The keys are thus unparsed entitys. I also
> think that prefixing with "urn" does not add value because all entrys will
> presumably do this.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [vote] context key string format
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 27 Nov 2002 22:04, Leo Simons wrote:
> If no-one objects, I will add a documentation snippet to the coding
> standards and find or write a utility class for making it easy to
> properly parse RFC 2141-formatted strings (probably
> org.apache.avalon.framework.context.ContextUtil).
I don't think it is useful to add in this class as keys are opaque strings
(much like keys to services). The keys are thus unparsed entitys. I also
think that prefixing with "urn" does not add value because all entrys will
presumably do this.
--
Cheers,
Peter Donald
*------------------------------------------------*
| You can't wake a person who is pretending |
| to be asleep. -Navajo Proverb. |
*------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>