CosNaming name equivalence
Jeffrey B. Stewart
- The CosNaming spec defines a name as a series of namecomponents, and a namecomponent as a pair of strings (id and kind). Throughout the spec, there is an implied concept of name equivalence. The natural interpretation of this is exact string matches on both id and kind for every component in the name. So, if that interpretation is used, then multiple bindings in a context can have the same id, as long as the kinds are different.
- Could a naming service add a restriction that the "id"s within a given context must be unique and still consider itself compliant? This doesn't seem to be explicitly allowed by the spec... They only say that "only one object can be bound to a particular name in a context." Again, the natural interpretation is that name equivalence is (!strcmp(id1,id2)&&!strcmp(kind1,kind2)). But if kind is simply meant to convey type information, this is not necessarily reasonable. It might make more sense to define equivalence as matching id only... The system would also be marginally more performant (very marginally), as it could avoid comparing kind's.
- On a different point, when they say that "a name of length 0 is invalid" does this mean that a name with 0 namecomponents is invalid, or does this mean that forcibly id != "". If so, does that imply that kind != ""?
- It's a grey area in the spec, and I'd very much like to hear people's opinions.
- Jeff Stewart
- -my opinions are my own and not those of my employer
Roland Turner
Jeffrey B. Stewart wrote:
> The CosNaming spec defines a name as a series of namecomponents, and a
> namecomponent as a pair of strings (id and kind). Throughout the spec,
> there is an implied concept of name equivalence. The natural
> interpretation of this is exact string matches on both id and kind for
> every component in the name. So, if that interpretation is used, then
> multiple bindings in a context can have the same id, as long as the
> kinds are different.
Interesting. I have not spent a lot of time looking at CosNaming, so
there's a fair chance that I've missed something, but my assumption was
the the "kind" component was nothing more than meta-information and not
part of the name resolution process at all.
Consequently, my assumption is that it is not meaningful (or legal) to
have to items bound in the same context with the same identifier,
differing only in kind.
I also would be interested in seeing other's opinions on this.
- Raz
Eric Snell
[Reply posted and mailed]
Jeffrey B. Stewart wrote:
>
> The CosNaming spec defines a name as a series of namecomponents, and a
> namecomponent as a pair of strings (id and kind). Throughout the spec,
> there is an implied concept of name equivalence. The natural
> interpretation of this is exact string matches on both id and kind for
> every component in the name. So, if that interpretation is used, then
> multiple bindings in a context can have the same id, as long as the
> kinds are different.
> Could a naming service add a restriction that the "id"s within
> a given context must be unique and still consider itself compliant?
> This doesn't seem to be explicitly allowed by the spec... They only
> say that "only one object can be bound to a particular name in a
> context." Again, the natural interpretation is that name equivalence
> is (!strcmp(id1,id2)&&!strcmp(kind1,kind2)). But if kind is simply
> meant to convey type information, this is not necessarily reasonable.
> It might make more sense to define equivalence as matching id only...
> The system would also be marginally more performant (very marginally),
> as it could avoid comparing kind's.
>
From the spec. 3.1.2 Names:
"A name component consists of two attributes: the identifier attribute
and the kind attribute. Both the identifier attribute and the kind
attribute are represented as IDL strings.
The kind attribute adds descriptive power to names in a
syntax-independent way. Examples of the value of the kind attribute
include c_source, object_code, executable, postscript, or " ". The
naming system does not interpret, assign, or manage these values in any
way. Higher levels of software may make policies about the use and
management of these values. ..."
I have always interpreted this to mean that only the id was used for
name binding and resolution. I think the phrase "The naming systems does
not interpret, ...", is the key here.
> On a different point, when they say that "a name of length 0 is
> invalid" does this mean that a name with 0 namecomponents is invalid,
> or does this mean that forcibly id != "". If so, does that imply that
> kind != ""?
> It's a grey area in the spec, and I'd very much like to hear
> people's opinions.
>
Definitely the Name sequence must have at least 1 NameComponent or the
name is invalid. In our implementation we also say that id == "" is
invalid.
> Jeff Stewart
> -my opinions are my own and not those of my employer
>
--
-------------------------------------------------------------------------
Eric A. Snell er...@pandasys.com
Panda Systems, Inc. "OO Consulting : CORBA, Java, C++"
Christian Callsen
However, take a look at section 3.2.2 in the CosNaming spec about "resolve":
"The resolve operation is the process of retrieving an object bound to
a name in a given context. The given name must exactly match the bound
name."
So, since the "resolve" signature accepts a CosNaming::Name the "kind"
field of every NameComponent DOES matter and IS part of the resolution.
-Christian Callsen
DISCLAIMER: I speak for myself and so does my company. Neat deal.
--
"The solution used to be to ask everyone on the Net. But then he graduated!?!"
"Faced with panic & terror, the solution was to `get connected'..."
Christian J. Callsen [ Christia...@Eng.Sun.COM ] ---- Sm:^le & Be Happy
Sun Microsystems SunSoft/NEO,2550 Garcia Av. MPK 18-209,Mountain View CA 94043
Paul Kyzivat
Roland Turner <r...@castle.net.au> wrote:
>Interesting. I have not spent a lot of time looking at CosNaming, so
>there's a fair chance that I've missed something, but my assumption was
>the the "kind" component was nothing more than meta-information and not
>part of the name resolution process at all.
>Consequently, my assumption is that it is not meaningful (or legal) to
>have to items bound in the same context with the same identifier,
>differing only in kind.
>I also would be interested in seeing other's opinions on this.
Well, I did spend a lot of time looking at it, and designed an
implementation of it. It was my interpretation that matching takes
place on both the name and kind fields - that these are abstractions
of the name and extension fields present in most file systems.
I agree that this is a hazy part of the spec.
My expectation was that different implementors of CosNaming would
probably take some liberties on what sorts of names are allowed, and
throw an exception if their particular restrictions were broken. For
instance, length of names, characters included in names, case
sensitivity, and so on. Disallowing two entries with the same name
but different kinds would also fall into this category.
Naturally, variations like this would affect the portability of
applications that use naming in particular ways. But given the very
open ended nature of the spec, I think it is inevitable that
restrictions will be applied.
Paul Kyzivat
Roland Turner
Christian Callsen wrote:
> Eric Snell <er...@pandasys.com> writes:
> > From the spec. 3.1.2 Names:
> >
> > "A name component consists of two attributes: the identifier attribute
> > and the kind attribute. Both the identifier attribute and the kind
> > attribute are represented as IDL strings.
> >
> > The kind attribute adds descriptive power to names in a
> > syntax-independent way. Examples of the value of the kind attribute
> > include c_source, object_code, executable, postscript, or " ". The
> > naming system does not interpret, assign, or manage these values in any
> > way. Higher levels of software may make policies about the use and
> > management of these values. ..."
> >
> > I have always interpreted this to mean that only the id was used for
> > name binding and resolution. I think the phrase "The naming systems does
> > not interpret, ...", is the key here.
> >
>
> However, take a look at section 3.2.2 in the CosNaming spec about "resolve":
>
> "The resolve operation is the process of retrieving an object bound to
> a name in a given context. The given name must exactly match the bound
> name."
>
> So, since the "resolve" signature accepts a CosNaming::Name the "kind"
> field of every NameComponent DOES matter and IS part of the resolution.
Only if you already assume that the Naming System does interpret the
"kind" attribute.
If you assume that it doesn't, then exact match referes to a matching of
"identity" attributes.
Eric has however dug up the phrase that I missed when I skimmed the spec
yesterday: It explicitly states that the naming system does not
interpret, assign or manage "kind" values. Matching them for names
represents interpretation and thus would directly violate this.
It seems that the kind attribute is indeed not part of the unique name.
Sadly, the spec does not acknowledge its author, so a direct question is
a little tricky. Anyone know who wrote it?
- Raz
Kerry Raymond
Jeffrey B. Stewart wrote:
> The CosNaming spec defines a name as a series of namecomponents, and a
> namecomponent as a pair of strings (id and kind). Throughout the spec,
> there is an implied concept of name equivalence. The natural
> interpretation of this is exact string matches on both id and kind for
> every component in the name. So, if that interpretation is used, then
> multiple bindings in a context can have the same id, as long as the
> kinds are different.
There is no simple answer (unfortunately); the spec is not clear on this
point:
"The kind attribute adds descriptive power to names in a
syntax-independent way. [...] The naming system does not interpret,
assign, or manage these values in any way. [...]
Higher levels of software may make policies about the use
and management of these values. This feature addresses the
needs of applications that use syntactic naming conventions
to distinguish realted objects. For example Unix uses suffixes
such as .c and .o. Applications (such as the C compiler) depend
on these syntactic convention to make name transformations
(for example, to transform foo.c to foo.o)."
So, on the one hand, the naming system does not interpret the kind
field, but it isn't clear whether you need to interpret something to test
for equivalence. The example suggests that ("foo", ".c") and ("foo", ".o")
are intended to be different and hence the kind field should be interpreted.
Individual vendors who have implemented the spec have recognised this and
made their own choice. I believe that you will find different products
making different interpretations.
This issue has been formally raised in the OMG some months ago, but
nothing happened as none of the original submitters of the naming
service have yet answered the question of what the original intention
had been. It should just be a question of clarification!
To summarise ...
If you have an implementation, then ask your vendor what it does, or
test it yourself and find out.
If you are developing an implementation, then I would recommend you
modularise your implementation so that you only have to fix one bit of
your code if the issue is finally resolved to the opposite of your
assumption.
Kerry
=============================================================================
Dr Kerry Raymond, Architecture Unit Leader E-mail: ke...@dstc.edu.au
CRC for Distributed Systems Technology Phone: +61 7 3365 4310
University of Queensland 4072 Australia Fax: +61 7 3365 4311
=========================================== WWW: http://www.dstc.edu.au/kerry
Paul Kyzivat
Roland Turner <r...@castle.net.au> wrote:
[snip]
>> However, take a look at section 3.2.2 in the CosNaming spec about "resolve":
>>
>> "The resolve operation is the process of retrieving an object bound to
>> a name in a given context. The given name must exactly match the bound
>> name."
>>
>> So, since the "resolve" signature accepts a CosNaming::Name the "kind"
>> field of every NameComponent DOES matter and IS part of the resolution.
>Only if you already assume that the Naming System does interpret the
>"kind" attribute.
>If you assume that it doesn't, then exact match referes to a matching of
>"identity" attributes.
>Eric has however dug up the phrase that I missed when I skimmed the spec
>yesterday: It explicitly states that the naming system does not
>interpret, assign or manage "kind" values. Matching them for names
>represents interpretation and thus would directly violate this.
>It seems that the kind attribute is indeed not part of the unique name.
>Sadly, the spec does not acknowledge its author, so a direct question is
>a little tricky. Anyone know who wrote it?
I think you are stretching for the interpretation you wish. (As are we
all!)
You can speculate that interpretation is required for matching, but I
don't think that is so obvious at all.
Now, if the kind field is not to be matched by resolve, then the
signature for resolve is silly - there is no point in passing kind
fields that are not used in any way. If we grant that the authors of
the spec were not being silly, then the kind fields are being passed
for a reason, and hence matching must have been intended.
Paul
Eric Snell
Paul Kyzivat wrote:
>
> Roland Turner <r...@castle.net.au> wrote:
>
> [snip]
> >> However, take a look at section 3.2.2 in the CosNaming spec about "resolve":
> >>
> >> "The resolve operation is the process of retrieving an object bound to
> >> a name in a given context. The given name must exactly match the bound
> >> name."
> >>
> >> So, since the "resolve" signature accepts a CosNaming::Name the "kind"
> >> field of every NameComponent DOES matter and IS part of the resolution.
>
> >Only if you already assume that the Naming System does interpret the
> >"kind" attribute.
>
> >If you assume that it doesn't, then exact match referes to a matching of
> >"identity" attributes.
>
> >Eric has however dug up the phrase that I missed when I skimmed the spec
> >yesterday: It explicitly states that the naming system does not
> >interpret, assign or manage "kind" values. Matching them for names
> >represents interpretation and thus would directly violate this.
>
> >It seems that the kind attribute is indeed not part of the unique name.
> >Sadly, the spec does not acknowledge its author, so a direct question is
> >a little tricky. Anyone know who wrote it?
>
> I think you are stretching for the interpretation you wish. (As are we
> all!)
>
Agreed. :-)
> You can speculate that interpretation is required for matching, but I
> don't think that is so obvious at all.
>
> Now, if the kind field is not to be matched by resolve, then the
> signature for resolve is silly - there is no point in passing kind
> fields that are not used in any way. If we grant that the authors of
> the spec were not being silly, then the kind fields are being passed
> for a reason, and hence matching must have been intended.
>
By that reasoning, all of the signatures which take a Name are silly if
none of them match on 'kind'.
From one potential use, your interpretation makes a lot of sense. For
example, ("foo", "c_source") and ("foo", "object_code") may be how a
user would like to use the naming service. Under the interpretation I
have, this is not legal - the second bind would fail.
I chose an interpretation based on the one sentence in the spec about
not interpreting the 'kind' field. I wonder if matching on id and kind
would break anyone who only expected to match on id? A clarification is
definitely needed.
> Paul
Roland Turner
Eric Snell wrote:
> Paul Kyzivat wrote:
> > I think you are stretching for the interpretation you wish. (As are we
> > all!)
> >
>
> Agreed. :-)
Seconded!
> From one potential use, your interpretation makes a lot of sense. For
> example, ("foo", "c_source") and ("foo", "object_code") may be how a
> user would like to use the naming service. Under the interpretation I
> have, this is not legal - the second bind would fail.
My assumption is that, like HTTP, the name and type are seperate. It
very common for a ".html" suffix to happen to be present on a text/html
document, but not certain. A ".shtml" or ".gi" is just as likely to
yield a text/html. In your example then, I'd see ("foo.c", "c_source")
and ("foo.o", "object_code") as being the intended use, but of course,
we are back to our basic problem.
- Raz
Keith Duddy
>[snip]
>>> However, take a look at section 3.2.2 in the CosNaming spec about "resolve":
>>>
>>> "The resolve operation is the process of retrieving an object bound to
>>> a name in a given context. The given name must exactly match the bound
>>> name."
>>>
>>> So, since the "resolve" signature accepts a CosNaming::Name the "kind"
>>> field of every NameComponent DOES matter and IS part of the resolution.
>>Only if you already assume that the Naming System does interpret the
>>"kind" attribute.
>>If you assume that it doesn't, then exact match referes to a matching of
>>"identity" attributes.
>>Eric has however dug up the phrase that I missed when I skimmed the spec
>>yesterday: It explicitly states that the naming system does not
>>interpret, assign or manage "kind" values. Matching them for names
>>represents interpretation and thus would directly violate this.
>>It seems that the kind attribute is indeed not part of the unique name.
>>Sadly, the spec does not acknowledge its author, so a direct question is
>>a little tricky. Anyone know who wrote it?
The short answer is that the specification is non-specific about how
to interpret Names. This has meant that implementers have had to make
a choice about matching. It seems that IBM, HP, Iona, Sun and others have
chosen to implement the semantics
if Name1.id == Name2.id AND Name1.kind == Name2.kind
then Name1 == Name2
else Name1 != Name2
There is a document by Sun and IBM: "Interoperable Naming Service -
Common Naming Conventions" which attempts to mail down some of the
things that are underspecified in the standard, as well as to provide
convenient string representations of Name strcutures. Sorry - can't
find the URL
K
--
__Keith Duddy___CRC for Distributed Systems Technology___+61 7 336 5 4310__
___ http://www.dstc.edu.au/AU/staff/keith-duddy.html ___ d...@dstc.edu.au___
Rich Salz
In <5dejdt$2...@azure.dstc.edu.au> d...@dstc.edu.au (Keith Duddy) writes:
>There is a document by Sun and IBM: "Interoperable Naming Service -
>Common Naming Conventions" which attempts to mail down some of the
>things that are underspecified in the standard, as well as to provide
>convenient string representations of Name strcutures. Sorry - can't
>find the URL
You can find it at:
http://www.software.ibm.com/clubopendoc/ins-cnc.html
They have a 130k postscript file that generates about 15 pages.
/r$
Jean-Sebastien Neveu
Paul Kyzivat wrote:
>
> Roland Turner <r...@castle.net.au> wrote:
>
> [snip]
> >> However, take a look at section 3.2.2 in the CosNaming spec about "resolve":
> >>
> >> "The resolve operation is the process of retrieving an object bound to
> >> a name in a given context. The given name must exactly match the bound
> >> name."
> >>
> >> So, since the "resolve" signature accepts a CosNaming::Name the "kind"
> >> field of every NameComponent DOES matter and IS part of the resolution.
>
> >Only if you already assume that the Naming System does interpret the
> >"kind" attribute.
>
> >If you assume that it doesn't, then exact match referes to a matching of
> >"identity" attributes.
>
> >Eric has however dug up the phrase that I missed when I skimmed the spec
> >yesterday: It explicitly states that the naming system does not
> >interpret, assign or manage "kind" values. Matching them for names
> >represents interpretation and thus would directly violate this.
>
> >It seems that the kind attribute is indeed not part of the unique name.
> >Sadly, the spec does not acknowledge its author, so a direct question is
> >a little tricky. Anyone know who wrote it?
>
> all!)
>
> don't think that is so obvious at all.
>
> Now, if the kind field is not to be matched by resolve, then the
> signature for resolve is silly - there is no point in passing kind
> fields that are not used in any way.
There is one. It is called encapsulation!
If I had to pass explicitly the "id"
of the name, then there would be no point in arguing what's the
definition of
"a match". Also, don't forget that a name is a sequence of name
components. If
I had to pass "id", logic dictates that I would have to pass the "id"s
of every
name components. I would have to convert my "name" which comes already
predefined
with the Naming COSS into a in-house type: sequence<IString>.
> If we grant that the authors of
> the spec were not being silly, then the kind fields are being passed
> for a reason, and hence matching must have been intended.
>
> Paul
--
------------------------------------------------------------
Jean-Sebastien Neveu
Consultant
Bell Sygma Inc.
700 de La Gauchetiere W., bureau 25N1
Montreal, Quebec, Canada, H3B 4L1
tel: (514) 391-2303 ,
pag: (514) 988-4487 <{><
fax: (514) 870-3004 `
. email: jsn...@qc.bell.ca
.
. .
.. , ,
:. \ <{>< <{><
.\ ><)> , ` , `
__d; '' , ><O)> <{>< / ,
_ \<,_ ><)> '' ` <({(>{
(_)/ (_) '' `` `
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kerry Raymond
There is little point arguing about the issue of name equivalence in
comp.object.corba. The fact is that the spec is ambiguous and this is
currently an open issue for the OMG Naming Revision task force.
If your organisation is an OMG member, then you can force a resolution
of this issue. Proceed as follows.
Decide what is right (I'm not entering into the debate). Go through the
spec and determine what needs to be changed to ensure that your preferred
interpretation is unambiguously specified in all relevant places. Write
it up with:
* a rationale for the changes you are proposing
* detailed editing instructions of the form (add this after para N of
section S, replace para N of section S with ..., delete para N of section
S) so everyone can see what the revised spec would say
Send this to the OMG Naming WG mailing list. Following any discussion
of it on that mailing list, it should be possible to put it to the vote
as part of the next revision cycle (I hear one might start at the March
meeting) so start preparing your spec changes now and it should be ready
for a vote by March.
Note that just sending a message saying the problem needs fixing a certain
way isn't helpful. Unless someone makes a detailed proposal to change the
spec, there is nothing to vote on and hence nothing will happen.
BTW, if your organisation is an OMG member, then you have a designated
technical representative to the OMG in your organisation. It probably would
be a good idea to discuss your proposal with that person first before
submitting it in case your organisation has some strong opinion on the
issue already.
Kerry
>>>> 1st International Enterprise Distributed Object Computing Workshop <<<<
>>>>>> Oct 24-26 1997 http://www.dstc.edu.au/events/edoc97/edoc.html <<<<<<
Michi Henning
Jean-Sebastien Neveu <jsn...@qc.bell.ca> writes:
>Paul Kyzivat wrote:
>>
>> Roland Turner <r...@castle.net.au> wrote:
>>
>> [snip]
>> >> However, take a look at section 3.2.2 in the CosNaming spec about "resolve":
>> >>
>> >> "The resolve operation is the process of retrieving an object bound to
>> >> a name in a given context. The given name must exactly match the bound
>> >> name."
>> >>
>> >> So, since the "resolve" signature accepts a CosNaming::Name the "kind"
>> >> field of every NameComponent DOES matter and IS part of the resolution.
>>
>> >Only if you already assume that the Naming System does interpret the
>> >"kind" attribute.
>>
>> >If you assume that it doesn't, then exact match referes to a matching of
>> >"identity" attributes.
>>
I ran into this problem quite some time ago and raised it with the
Naming working group in the OMG. Unfortunately, all the original authors
seem to have lost interest, and the working group is effectively defunct
(in the sense that no-one seems interested in nailing down the spec).
There are actually a whole host of minor defects in the Naming Service
spec - the fact that name equivalence is undefined is probably the
most serious one.
I managed to track down two of the original authors of the spec to seek
clarification. The answer I got was that the *intent* of the spec
was to compare both id and kind for equivalence.
This raises some interesting issues. I presented these issues to the
original authors, but never got a reply. Here is a summary of why I think
name equivalence should be established by comparing only the id fields,
and ignoring the kind fields:
1) The interface caters for the special case more than the general case
The original intent of the kind field (as explained to me by one
of the original authors) was to play the role of the .xxx extensions
in file names. The idea is that you can have foo.exe and foo.txt
and have the treated differently.
This is bad because it caters for the special case more than the
general case. It assumes that most names will have two parts,
which I believe is a wrong assumption - CORBA names will be used
for lots of things (most of them *not* file names), and it is
highly unlikely that the majority of these names will naturally
have two components.
2) Source code is unnecessarily complicated
Consider the source code you need to write if you do not need
the kind fields and only want to use the id fields:
Suppose I want to look up the name <mgmt apps app123> (all these are
id fields, kind fields are not used). You need to write (in C++):
//
// We are looking for /mgmt/apps/app123.
//
CosNaming::Name name;
name.length(3);
name[0].id = (const char *)"mgmt";
name[0].kind = (const char *)"";
name[1].id = (const char *)"apps";
name[1].kind = (const char *)"";
name[2].id = (const char *)"app123";
name[2].kind = (const char *)"";
obj = inc->resolve(name);
I need to do this because it is illegal to pass a NULL pointer across
an interface, and because I need to keep the kind fields in a defined
state, even if I don't want to use them.
This is a classical case punishing 99% of the developer community for
a feature required by 1%. If kind fields did not exist, the code would
be:
//
// We are looking for /mgmt/apps/app123.
//
CosNaming::Name name;
name.length(3);
name[0].id = (const char *)"mgmt";
name[1].id = (const char *)"apps";
name[2].id = (const char *)"app123";
obj = inc->resolve(name);
3) There is no need for two keys
The Naming Service does not impose any restrictions on the byte values
contained in a name component. This means that if I *do* have an
application which would like to use two-part names, I can always
use a single key by simply concatenating the different parts of the
name.
For example, foo.exe and foo.txt can be represented as either
id = foo and id = foo
kind = exe king = txt
or I can simply use
foo.exe and foo.txt
You can argue that for some names, a convenient separator is not
available. However, I don't think this is a strong argument, because
byte-stuffing can always be used to escape a separator that may
also occur as part of a name.
4) Two keys may not be enough
If two keys (id and kind) are better than one, then surely *three*
keys must be better still. Of even better, why not forty-two? If
there is a strong anticipation that lots of application will want
two-part names, surely there will be some that want three-part
names. Why are these not explicitly catered for?
Of course, the answer is that there is no need to, just as there
is no need to specifically cater for two-part names.
5) You can achieve multi-part names with contexts
The kind fields are redundant because the same thing can be
achieved by using a context to represent the kind. For example,
instead of using names like
files/foo(exe) and files/foo(txt)
you can use
files/exe/foo and files/txt/foo
Note: I have used / as a component separator, and shown the kind
value in parenthesis here - of course, these would not be present
in the actual name components.
On the other hand consider what happens if the kind fields are ignored
for the purposes of name equivalence, and are simply carried around
as a descriptive value. In that case, you could use the kind field
to indicate things like:
X.500 name
UNIX name
PA-RISC executable
SPARC executable
DOS text file
UNIX text file
When you resolve a name, you simply specify the id field value. The
search proceeds by ignoring the kind value. When the name is resolved,
the kind field would be returned by the resolve and would serve as
an annotation that says something extra about the name.
One consequence of this is that you cannot have foo(txt) and foo(exe)
in the same context, because the two names would be considered
equivalent. However, you could of course have foo.txt and foo.exe,
by simply concatenating with a separator.
Here is my overall opinion:
1) The kind fields are redundant and harmful and should therefore
be removed.
2) If they are to be retained, I believe they should not be used to
establish name equivalence (the current wording of the spec
permits that interpretation, and some may even argue even suggests it).
3) Until the issue is resolved in the OMG, the safest thing to do is
to always set the kind field to the empty string (in other words,
not use it). Otherwise, existing code may break depending on which
way the decision is made.
Michi.
--
--
Michi Henning +61 7 33654310
DSTC Pty Ltd +61 7 33654311 (fax)
University of Qld 4072 mi...@dstc.edu.au
Paul Kyzivat
Jean-Sebastien Neveu <jsn...@qc.bell.ca> wrote:
>> Now, if the kind field is not to be matched by resolve, then the
>> signature for resolve is silly - there is no point in passing kind
>> fields that are not used in any way.
>There is one. It is called encapsulation!
>If I had to pass explicitly the "id"
>of the name, then there would be no point in arguing what's the
>definition of
>"a match". Also, don't forget that a name is a sequence of name
>components. If
>I had to pass "id", logic dictates that I would have to pass the "id"s
>of every
>name components. I would have to convert my "name" which comes already
>predefined
>with the Naming COSS into a in-house type: sequence<IString>.
But, if your intent was to define COS Naming while only matching on
the ID, you would never define Name that way. Instead, Name would be a
sequence of IDs. The Kind field would be a property that could be
provided in addition at time of Bind, and that could be obtained,
perhaps as part of List.
Paul
Paul Kyzivat
mi...@dstc.edu.au (Michi Henning) wrote:
[snip]
>3) Until the issue is resolved in the OMG, the safest thing to do is
> to always set the kind field to the empty string (in other words,
> not use it). Otherwise, existing code may break depending on which
> way the decision is made.
I can agree with this statement. (But none of the rest. :)
Paul
Jean-Sebastien Neveu
That would require availability of Property services which I don't
expect
in a near future. In the meantime, it seems perfectly logical to me to
encapsulate
the "kind" within the name.
Anyway, are you trying to tell me every time you overload the '='
operator for
one of your custom class, you use every single attributes of that class.
I would doubt it seriously. I don't think performance is a serious
enough concern
here to compromise the encapsulation concept.
Roland Turner
Michi Henning wrote:
> I managed to track down two of the original authors of the spec to seek
> clarification. The answer I got was that the *intent* of the spec
> was to compare both id and kind for equivalence.
I'm amazed.
However, as someone pointed out, we tend to see things the way that we
want to...
> 1) The interface caters for the special case more than the general case
>
> The original intent of the kind field (as explained to me by one
> of the original authors) was to play the role of the .xxx extensions
> in file names. The idea is that you can have foo.exe and foo.txt
> and have the treated differently.
>
> This is bad because it caters for the special case more than the
> general case. It assumes that most names will have two parts,
> which I believe is a wrong assumption - CORBA names will be used
> for lots of things (most of them *not* file names), and it is
> highly unlikely that the majority of these names will naturally
> have two components.
Directory names, table names, hostnames, domains names, no doubt even
less obvious things that haven't occurred to me yet.
> 3) There is no need for two keys
Definitely. To arbitrarily break the identifier into two parts just
doesn't make sense (and, as you suggested in a comment that I didn't
quote, requires the intialisation of lots of nulls, in most cases).
The very fact that the components are called "id" and "kind" suggests
that the first identifies the item (within a context) and the second
does not. Why call someting "id" if it doesn't identify something?
> The Naming Service does not impose any restrictions on the byte values
> contained in a name component. This means that if I *do* have an
> application which would like to use two-part names, I can always
> use a single key by simply concatenating the different parts of the
> name.
Almost. "id" and "kind" can contain anything except the null character.
> For example, foo.exe and foo.txt can be represented as either
>
> id = foo and id = foo
> kind = exe king = txt
>
> or I can simply use
>
> foo.exe and foo.txt
Note quite, you'd have to use foo\0exe and foo\0txt, which would be
difficult to compare in many languages. Otherwise, "foo" "exe would be
indistinguishable from "foo.exe" "".
> 5) You can achieve multi-part names with contexts
Possibly ugly. (Considering a filesystem anmespace) "several files in a
directory" ideally maps to "several items in one context" would now map
to a hierachy of contexts.
> On the other hand consider what happens if the kind fields are ignored
> for the purposes of name equivalence, and are simply carried around
> as a descriptive value. In that case, you could use the kind field
> to indicate things like:
>
> X.500 name
> UNIX name
> PA-RISC executable
> SPARC executable
> DOS text file
> UNIX text file
In fact, when I first read the spec what went through my mind was MIME
types. Here is an arbitrarily (and locally) extensible set of type
descriptors that is globally used and is growing rapidly to cater for
almost every conceivable content type.
> One consequence of this is that you cannot have foo(txt) and foo(exe)
> in the same context, because the two names would be considered
> equivalent. However, you could of course have foo.txt and foo.exe,
> by simply concatenating with a separator.
Which is of course what we already have in most environments anyway. The
suffix serves not only to identify the type of the contents, but also to
distinguish items that would otherwise have clashing names.
> 1) The kind fields are redundant and harmful and should therefore
> be removed.
In the same sense that Content-type: is useful in MIME environments, I
think that the kind fields are useful and should be retained, but their
role should be clearly defined.
> 2) If they are to be retained, I believe they should not be used to
> establish name equivalence (the current wording of the spec
> permits that interpretation, and some may even argue even suggests it).
In light of your arguments, even if the spec specifically stated that
kind matching should be used, I'd agree with you that it should be
changed to say that it shouldn't be used.
> 3) Until the issue is resolved in the OMG, the safest thing to do is
> to always set the kind field to the empty string (in other words,
> not use it). Otherwise, existing code may break depending on which
> way the decision is made.
Phooey.
(I do actually agree with you, but will probably actually utilise them
anyway :-))
- Raz