[omniORB] Interoperable Naming Service Available

[Duncan Grisby]

I have just checked in support for the Interoperable Naming Service
under omniORB 3. You can get it from the CVS server, and it will
appear in tomorrow's FTP snapshot. (Don't be alarmed when the snapshot
is smaller than today's one -- I have also removed the old omniidl2
sources, which were no longer needed.)

omniORB 3 now provides all of the required INS functions specified in

  http://www.omg.org/cgi-bin/doc?ptc/99-12-03

The following is a summary of the important changes.


Building difficulties
=====================

If you update an existing CVS checkout of the omni3_develop branch,
you will find that you get build errors, because some of the changes
aren't spotted by the makefiles. To prevent the errors, you should:

  1. Delete all of the .d dependency files. On Unix you can use a
     command like

       find . -name "*.d" -print | xargs rm

  2. Delete src/lib/omniORB2/Naming*

The changes are significant enough that pretty much everything gets
rebuilt anyway, so an alternative is to delete everything and start
with a fresh checkout.

Other than this, if you don't use any of the new features, you
shouldn't notice anything different.


ORB Core changes
================

1. The ORB::string_to_object() function now accepts corbaloc: and
   corbaname: format strings, as well as IOR: strings.

2. The standard -ORBInitRef and -ORBDefaultInitRef command line
   arguments are supported.

3. The omniORB configuration file (or NT registry) now also has keys
   named ORBInitRef and ORBDefaultInitRef, so before where you had a
   file containing something like

     NAMESERVICE IOR:...

   you can instead have

     ORBInitRef NameService=IOR:...

   This means you can configure resolve_initial_references() to know
   about any name you like.

   All of the old configuration file keys are still supported.


omniNames changes
=================

1. omniNames now supports the extended CosNaming::NamingContextExt
   interface.

2. omniNames is able to read and use the log file from either the
   older omniORB 3 omniNames, or the omniORB 2.8 omniNames. In this
   case, any stored NamingContext references will remain valid.
   (Before now, omniORB 3's omniNames could not read omniORB 2.8's log
   files.)

3. When you start omniNames for the first time with the -start option,
   you no longer have to specify a port number. If you do not specify
   one, the standard port of 2089 is used. You can still specify a
   different port if you wish.

3. If you are not using a log file from an earlier omniNames, the root
   NamingContext now has the object key "NameService", which makes
   corbaname: URIs more pleasant.

   In particular, if you start omniNames on a machine named
   wobble.example.com with the command

     omniNames -start

   then you can refer to it in omniORB.cfg like:

     ORBInitRef NameService=corbaname::wobble.example.com

   (or the old-style

     NAMESERVICE corbaname::wobble.example.com
   )


nameclt changes
===============

1. nameclt's mapping of CosNaming::Names to strings pre-dated the INS
   specification, and differed in a few minor respects. nameclt now
   uses the standard stringified Name format. You will probably only
   notice this if you have NameComponents with empty strings in both
   the id and kind fields.


Enjoy!  Report bugs...

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --