[omniORB] omniORBpy: persistent IORs and/or LifeCycle support?

[Duncan Grisby]

On Wednesday 24 May, Mark Borges wrote:

> I guess my reluctance in building this interface using omniORB 3 is
> the (perhaps mistaken) presumption that omniORB 2.8 is more thoroughly
> tested and robust than the latest omniORB 3 pre-release, and the fact
> that omniORBpy has only worked with omniORB 3 since March.

Although omniORBpy has worked with omniORB 2.8 for longer than with
omniORB 3.0, it was always designed to work with 3.0, and is just as
stable on 3.0 as 2.8. I definitely recommend that omniORBpy users use
3.0 rather than 2.8.

> But perhaps for my platform of interest (Solaris-2.6/gcc-2.95.2) this
> is not true; are there any remaining known problems? Is the major
> "feature" lacking in omniORB 3 merely documentation[1]? Any comments
> w.r.t. stability/performance of omniORB 3 vs. omniORB 2.8?

I've just checked in a draft version of the omniORB 3 manual, so that
obstacle to release is nearly cleared. We want to do a bit more
testing before we consider it ready for release, but for most purposes
it should be stable.

> [1]  By the way, is there any contribution we (users of omniORBpy)
>      could make in the way of writing or formatting documentation, or
>      submitting example code? I did see the survey request of Sai-Lai

Thanks for the offer, but it will probably take longer to get the
things which need to be done finished if we start taking external
contributions.

The main thing which everyone can do is try omniORB 3 and report any
problems they have. That way we'll make sure it's a stable as possible
at release.

Cheers,

Duncan.

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