[omniORB] Introduction..

[Duncan Grisby]

On Monday 20 December, "F. Michel" wrote:

> Since, CosNaming::NamingContext is part of libomniORB2, we cannot mixit with
> our implementation of this object. An additional compile flag
> (NO_OMNI_NAMES for instance) gives us the behaviour we need with
> really little changes to the source and does not impact the nominal
> behaviour.

Oh I see -- you have an interface which calls itself
CosNaming::NamingContext, which has a different interface to the
standard one!  I definitely don't think we should encourage such nasty
behaviour by adding make options. Is there any way you can convince
the necessary people to make a different interface, derived from
CosNaming::NamingContext?


[...IDL compiler name stripping...]

> In what form do you expect patches, I can join diffs to my next mail.

Feel free to send some diffs. Note that we won't necessarily include
them in the distribution. Also, we're in the process of re-writing the
IDL compiler to be completely different, so we're not enormously keen
to keep fiddling with the old one.

[...]

> > The C++ mapping makes Environment an option if you don't have genuine
> > C++ exceptions. Its use isn't necessary with omniORB, and I think it
> > would be a backward step to provide an option to include it.
> 
> Agreed. Indeed one of our targets does not support C++ eh. However
> we can implement locally an additional "portability" layer.

Are you going to try to run omniORB on a platform without C++
exceptions?  omniORB absolutely requires exceptions.


> (The firewall here won't allow cvs access. Is there any repository
> where I could find diffs instead of the whole source tree ?)

I think it would be far too much hassle to automatically maintain
diffs between different revisions. That's what CVS is for afterall.
There is, however,

  http://www.uk.research.att.com/omniORB/omniORBbug.html

which contains patches for some bugs.

> About refcount retrieval, the patch I'd propose consists in moving
> a method of the omniObject class from the private space to the
> public. I think omniObject is not part of OMG standard, is it ?

Unfortunately, that change will make the interface incompatible with
the old interface (on some platforms anyway), so it would require a
major version number change. We'll consider making the change to later
versions.

Cheers,

Duncan.

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