Summary: The Name equivalence issue has appeared in comp. object.corba. Follow up posting from Michi Henning

Summary: The "list" operation to access the bindings within a naming context has an overly verbose return type. Could it (and some of its exceptions) be simplified?

Summary: The name service doesn"t really specify when false is first returned. Is when it returns the last one, or when it is already pointing out of range?

This is simply an administrative error, the table of contents within the document does not reflect the fact that the lightweight naming chapter (chapter 3) was incorporated into the document

Summary: Naming Service spec: "The kind attribute adds descriptive power to names.."(p. 3-2) Interpretation: kind value is opaque, never looked at, carried arround with each name. Interpretation correct?

Summary: It is open to interpretation as to whether FALSE is returned with the last valid binding or after the last valid binding. Call next_one one more time after last valid binding to get FALSE?

Summary: Proposal to revise the Naming Service. p. 3-6 and 3-12 of CORBAservices replace the definition of Binding

Summary: The destroy operation was the only option in original spec before Lifecycle spec. By inheriting from LifeCycleObject, we get the remove operation which does same as destroy.

Summary: When next_n returns FALSE, it needs to be specified what happens to the out parameter bl. Spec should mandate that lenght of returned sequence must be zero.

Summary: next_n returns a boolean value. It is specified nowhere what the return value means in various cases

Summary: Naming Service implementation should be free to destroy an iterator as soon as last value has been retrieved. Clients should be allowed to call next_one or next_n after one of these calls.

Summary: Text for destroy should be updated to state that a call to destroy after next_one or next_n have returned FALSE may no longer be valid and may raise OBJECT_NOT_EXIST.

Summary: Text explains when the NotFound exception is raised, but it does not explain the meaning of "why"member in the exception. Why can be missing node, not_context, not_object

Summary: The spec says nothing about whether the Naming Service is allowed to return fewer than requested number of bindings.

Summary: The return value from next_one is specified as "If there are no more bindings, false is returned". What is returned if there is another binding?

Summary: The spec says nothing about how to say "as many as you can" with the value of how_many. Specify that how_many value should return as many bindings as it can in a single call.

Summary: Problem understanding benefits of Names Library. There are differences between what the standard says and what the pseudo-IDL for the names library says.

The NamingContextExt interface has a resolve_str
operation that takes a string and returns its
binding.

I suggest to add a converse bind_str operation:

void bind_str (in StringName sn, in Object obj)
raises (NotFound, CannotProceed, InvalidName,
AlreadyBound);

That would allow not only lightweight clients to
use the Naming Service, but also lightweight servers
to publish their references as easily as possible.

(And a Lightweight Naming Service would be possible
that just implemented these two operations.)

The latest INS doc 99-12-03.pdf explains the order the Initial reference
should be resolved is
1. Try using -ORBInitDef definition
2. Try using -ORBDefaultInitDef defintion
3. Then finally try with Pre-Configured ORB Settings.

The above would be the resolve_initial_references protocol. Now, If the user
sets a -ORBInitDef in the format

-ORBInitDef NotificationService=corbaloc:rir:/NotificationService

If the user does orb.resolve_initial_references( "NotificationService" )
then according to the spec, r_i_r() first checks -ORBInitDef's, In this case
finds one and also finds that the NotificationService can be obtained by
r_i_r()
again it calls the same method. Doesn't this lead to an infinite loop ?

I am just reflecting over the optional IOR syntaxes using file:// and
http:// URI's and have one suggestion. URI's sport a `fragment identi-
fier', i.e. an identifier following a hash sign.
Now this fragment identifier could be useful to disambiguate between
many IORs in the referenced file. I can think of several possibilities:

1.) The fragment-id is numerical. The file contains many IORs, separated
by newlines, and the fragment-id is an index into the file.

2.) The file contains many lines of the format `identifier WS IOR', i.e.
a simple tab-separated table. The fragment-id denotes the first IOR
where the identifier matches.

3.) The ORB checks each IOR in the file and looks for one whose Reposi-
tory Id matches the fragment-id.

Section 4.8.2 of ptc/99-12-03 should specify at what time strings
given to -ORBInitRef are processed into object references. Should they
be processed during ORB_init() and stored for later use by
resolve_initial_references(), or should they be processed each time
resolve_initial_references() is called?

This matters for corbaname: (and file:, http:, etc.) URIs whose
resolutions can change over time.

If they are processed at ORB_init() time, are they processed in the
order they were specified on the command line? Suppose an ORB with an
administratively configured NameService reference is called with a
command line of

-ORBInitRef Foo=corbaname:rir:#foo -ORBInitRef NameService=IOR:...

If ORB_init() processes the arguments into object references in order,
foo will be looked up in the administratively configured name service,
rather than the one specified on the command line. This may or may not
be considered a useful feature.