Issues for Interoperable Naming Service FTF mailing list

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

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

Issue 3100: fragment part in file: or http: IOR
Issue 3360: INS Issue: Orderof how the Initial reference is resolved
Issue 3535: INS Issue: When are -ORBInitRef arguments processed?
Issue 5926: Binding a Stringified Name
Issue 9811: FormalNumber: formal/04-10-03, Section TOC

Issue 3100: fragment part in file: or http: IOR (naming_ftf)

 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.

 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 ?

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.

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.)

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