[omniORB] Introduction..

[F. Michel]

Duncan Grisby wrote:

> On Friday 17 December, "F. Michel" wrote:
>
> > - Naming service. Our product provides its own naming service
> > with an externalization method. It was initially developped using
> > OMG specification and now that all ORBs implement this service
> > we experience lots of name clashes. Well, I won't really agree with
> > this initial choice, but I have to deal with, so... Could it be possible
> > to
> > make omniORB naming service an optional feature ? (few ifdefs...)
>
> You don't have to use omniORB's Naming service if you don't want to.

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.

>
>
> > - Keep include paths in generated stubs. This is a "nice to have"
> > feature. I've implemented a "-K" options which allows to keep
> > include paths and to remove given prefixes from the absolute paths.
>
> This is a potentially useful feature, but becomes less important if
> you use a sensible makefile set-up. If you send us your patches, we'll
> consider including them.

The patch consists in maintaining a list of prefixes which may beremoved from
absolute paths.  The functionality is implemented
in stripped_name in idl.ll. Instead of keeping only the last component
of the path, we remove the given prefix.

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

>
>
> > - Skeleton generation. The purpose is to generate a dispatch method
> > inside the interface class rather than generating a skeleton class
> > for servers. This is a quite personal approach of the BOA but it allows
> > diamond inheritance between interfaces.
>
> I don't understand this. Can you explain more?  There's nothing
> preventing you using diamond inheritance with the current IDL compiler
> is there?

Well, this is not a simple issue. I'm currently trying to isolate a
simplecase where the skel inheritance won't work. I'll submit it to you
later.

>
>
> > - CORBA::Environment. Orbix provides an additional parameter to
> > all distributed methods. We never use this parameter but it's in the
> > code. I've added an option to generate this parameter with default
> > values for operations and attribute access methods.
>
> 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.

> > Something different: I've noticed a problem with name lookup. An
> > identifier is now searched only in the first inherited level.
> > ( An interface A defines an exception ex. B inherits from A and C
> > inherits from B. C defines a method which raises an ex. There, ex
> > is said not to be defined.)
> > This worked with omniidl2 V 2.7.1.
>
> This is a bug which was introduced in fixing a similar bug :-(. The
> fix will appear in CVS and FTP snapshots overnight.
>

OK applied, thanx.

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

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 ?

Nyny