Re: ORBit2 port? (was Re: _narrow() patch to CORBA::ORBit dropped?)

[Huw Rogers <count0 building2 co jp>]

> Before we get two involved with ORBit2, I think the first priority is to
> put in a couple of simple patches into CORBA::ORBit and then make a
> 0.4.4 release.

Here's the list of fixes I intend to put in 0.4.4, as per my patch:

1] require ORBit 0.5.13 in Makefile.PL
2] up version to 0.4.4
3] idl_path fix (fix originally from Owen?)
4] support declaration of global enums in IDL
5] null / void Any support
6] various spelling/typo corrections in error messages
7] _narrow() patch (from Alex)
8] _is_a() fix
9] create_reference_object_with_id() renamed to
     create_reference_with_id () (suggestion from mail list)
10] CORBA::MICO reference in ORBit.xs fixed to CORBA::ORBit
11] marshalling / demarshalling of complex mixed sequences of in, inout
       and out parameters fixed to comply with Owen's Perl mapping spec
12] references to mico renamed to orbit in error messages
13] XSRETURN() appropriately from stubs according to GIMME_V (wantarray),
       for correct behaviour in array, scalar and void contexts
14] non-portable C constructs fixed (tested on Solaris / WorkShop CC)
15] typecode memory management bug fix
16] check arguments to _repoid()
17] reduced fragility of put_objref()

> After that, I'm quite keen on ORBit2 as I would like to reduce the
> number of different ORBS I have to use. At the moment I use:
> 
> C++: TAO
> C: ORBit
> Perl: ORBit, COPE, Mico (need the IFR for COPE)
> 
> In the longer term I think ORBit2 can eventually fill all those niches,
> which would save a _lot_ of configuration management (not to mention
> mailing list reading...).

ORBit2 is attempting to multithread existing single threaded software.
Other than simple wrapping exercises, I've only ever seen this done a
very few times successfully. With the GNU C library the effort took
anywhere between 10 and 100 man years depending on how pessimistic you
want your historical perspective to be and what eventually resulted was
essentially a rewrite. I don't think anyone could really claim a lower
number than mine, and in any case I don't want to spend more than a
couple of months on this. If the MT changes to ORBit2 didn't have the
potential to impact the single threaded reliability / performance /
functionality I wouldn't be concerned, but I'm witholding a positive
opinion until someone who really knows can allay these concerns.

Also all of this work we're contemplating goes out of the window with
Perl6 / parrot, which will apparently be properly multithreaded and
which I am looking forward to doing some CORBA work with. So I'm
inclined to keep ORBit around for now until single threaded Perl5 (and
associated stuff like mod_perl and Apache) is finally laid to rest and
Perl has something to kill J2EE with (CORBA being a necessary part of
that strategy).

However, if someone can say authoritatively that ORBit2 is fine, it's
better, it isn't that different, just use it, then we should migrate.

	-Huw