Issue 2953: Problems with step-wise resolution                                                                                                                                                                      (naming_ftf)
Source: Cisco Systems (Mr. Paul Kyzivat, pkyzivat@cisco.com)
Nature: Uncategorized Issue
Severity: 
Summary: The specification of the NamingContext interface distinguishes between
object and context bindings. It requires that when a multi-component
name is resolved, each name other than the last must designate a context
binding - an object binding to an object that happens to conform to the
NamingContext interface shall not be sufficient.

This restriction is easy for a name server to support, because it has
direct access to the binding information. (In fact, multi-component
resolution is easier for the server with this restriction because it
need not narrow an object reference to determine if it is a
NamingContext - a potentially expensive operation.) 

However this restriction places an unacceptable burden on "an
application that chooses to do piecewise resolution". As things stand,
an application that wishes to do piecewise resolution in a conforming
way must first list each context in order to determine the binding type
of the component at the next level. (There are many reasons to do
step-wise resolution. For instance, some piece of code may have a
"working context" in which it stores bindings. A client of it may be
responsible for selecting the working context and providing it as an
object reference. Also, when federated naming contexts are used,
stepwise resolution can be a significant performance win.) The cost of
doing the list can be arbitrarily high, depending on the number of
bindings in the context.

Resolution: Decided not to add extra operations to support this particular client case.
Revised Text: 
Actions taken:
October 5, 1999: received issue
May 4, 2000: closed, no action taken
Discussion: 

End of Annotations:=====
Date: Tue, 05 Oct 1999 10:17:40 -0400
From: Paul H Kyzivat <paulk@roguewave.com>
Organization: NobleNet
X-Mailer: Mozilla 4.0 [en] (WinNT; I)
MIME-Version: 1.0
To: issues@omg.org, Naming FTF <naming_ftf@omg.org>
Subject: Problems with step-wise resolution
X-Priority: 3 (Normal)
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
X-UIDL: oLFe9oJT!!K)E!!Fa9!!

The specification of the NamingContext interface distinguishes between
object and context bindings. It requires that when a multi-component
name is resolved, each name other than the last must designate a
context
binding - an object binding to an object that happens to conform to
the
NamingContext interface shall not be sufficient.

This restriction is easy for a name server to support, because it has
direct access to the binding information. (In fact, multi-component
resolution is easier for the server with this restriction because it
need not narrow an object reference to determine if it is a
NamingContext - a potentially expensive operation.) 

However this restriction places an unacceptable burden on "an
application that chooses to do piecewise resolution". As things stand,
an application that wishes to do piecewise resolution in a conforming
way must first list each context in order to determine the binding
type
of the component at the next level. (There are many reasons to do
step-wise resolution. For instance, some piece of code may have a
"working context" in which it stores bindings. A client of it may be
responsible for selecting the working context and providing it as an
object reference. Also, when federated naming contexts are used,
stepwise resolution can be a significant performance win.) The cost of
doing the list can be arbitrarily high, depending on the number of
bindings in the context.

To address this problem, I propose that some additional operations be
provided on naming contexts:

        resolve_type is similar to resolve except it returns both
                       an object and the binding type of the object.

        resolve_context is similar to resolve except it returns
                       a NamingContext and raises an exception if
                       the name denotes an object binding

        resolve_object is just like resolve except it raises an
                       exception if the name denotes a context
binding.

With these new operations, resolve is redundant but should of course
be
retained for backward compatibility.

Strictly speaking, resolve_type is sufficient by itself, but
resolve_context would be very convenient to have. The resolve_object
operation is less justified and is offered mostly for symmetry. So if
people want to minimize changes I would suggest added only
resolve_type
or resolve_context.

With these additions, piecewise resolution can be done by using
resolve_context for all intermediate names, and ordinary resolve (or
resolve_type) for the final name.