?Re: [omniORB] Introduction..

[flynch@usa.net]

Some comments in-line...

>I'm currently using version 2.8.0 (last stable release) and
>my job for now is to provide an "industrial" version of a
>product that was initially developped with Iona's Orbix.

For "industrial" work I'd recommend a POA based ORB like omniORB3 or Orbix2000

>Here is a list:
>- RefCounting. For explicit object management we need to
>know the refount of CORBA objects as well as our local objects.
>omniObject only provides a private method for refCount retrieval.
>Is there a reason why it couldn't be public (or at least protected) ?
>

I agree 100% being able to get the refCount of a CORBA object is extremely usefull. (Even if it requires a non-standard API :-)

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

AFAIK Using the omniORB naming service is optional, resolve_initial_references returns an object reference that you have specified (in a strinafied form) in the config file. So provided you have implemented a CORBA compliant namgin service (ie you implement CosNaming::NamingContext)  this should not be an  issue. 

>- 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 agree with this again, there is no point in having all the generated code linked with both clients and servers. FATWARE is not good. Splitting the client and server side generated code is a good thing.

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

This CORBA::Environment is used in Orbix to support compilers that do not have native C++ exceptions, and also for timeouts on operation calls. 
This parameter has been dropped with Orbix2000, and I don't think that there is any reason that it should be added to omniORB. 
BTW Orbix's use of this parameter *IS* CORBA compliant. The spec states that each method *may* take CORBA::Environment as a parameter. I suggest that you consider implementing a portability layer that would allow you to target several different ORB's.

Regards,
Frank