Issues for Naming Working Group of the CORBAservices RTF-defunct email list

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 24: List binding return type
Issue 64: BindingIterator
Issue 270: Name comparisons
Issue 271: Open Interpretation for next_one
Issue 272: Specification of return value from next_one
Issue 273: next_n return
Issue 274: Specification of out parameter bl
Issue 275: Value of how_many
Issue 276: Fewer returns of requested number of bindings
Issue 277: Destroying an iteratorr
Issue 278: Text for destroy should be updated
Issue 279: Destroy operation in original spec
Issue 280: Changes to struct binding
Issue 281: Names Library Benefits?
Issue 298: Meaning of "Why"member in the NotFound exception

Issue 24: List binding return type (naming)

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?

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: 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: next_n returns a boolean value. It is specified nowhere what the return value means in various cases

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: 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: The spec says nothing about whether the Naming Service is allowed to return fewer than requested number of bindings.

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: 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: Proposal to revise the Naming Service. p. 3-6 and 3-12 of CORBAservices replace the definition of Binding

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.

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