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

[Huw Rogers <count0 building2 co jp>]

> > BTW I'd be interested in your thoughts on a port to orbit2.
> 
> See the mail I resent to the list this morning... I discussed it
> a bit there.
> 

ORBit2 was (is?) slower and less reliable / interoperable, without
adding significant value over ORBit. It had (has?) problems which were
fixed in ORBit since the fork, but not in ORBit2 (such as typecode
alignment / memory issues, interoperability issues with Any, etc.) It's
principal focuses of development activity relative to ORBit appear to be
things which don't directly benefit orbit-perl, such as a C++ mapping
and multithreading. These impressions from reading the mailing lists and
the various README/TODO/FAQs, many of which are old information.

If ORBit is going to be replaced by ORBit2 (hasn't happened yet),
another option is to take the bits of ORBit actually used by orbit-perl
and bring them into orbit-perl (I have the impression that orbit-perl
only actually uses a small fraction of the ORBit source, excepting
libIDL).

If ORBit2 has any of these issues resolved, those would be in it's
favour. This is kind of a new draft TODO for orbit-perl:

* marshalling/demarshalling speedups (originally ORBit2 was slower than
ORBit at this)
* comprehensive POA non-default policies support (from orbit-perl TODO)
* fixing of the request ID = alloca(0) stuff (from orbit-perl client.c)
* float/double correctness (from orbit-perl demarshal.c)
* interface repository (from orbit-perl TODO)
* Comprehensive testing of deadlock call-forward / call-back scenarios
(server A calls server B, which does a nested callback to server A,
which does a nested callforward to server B, etc. all on the same
connection) (gut feel that this is probably a problem, especially when
interoperating with ORBs with different threading / connection models)
* interoperable any and dynany support (any is mostly ok with my patch,
but haven't looked at dynany at all)
* recursive IDL type support (this is needed)
* miscellaneous CORBA 2.4 / 2.5 IDL (predeclaration of types, etc.)
* corbaloc support (requires POA that supports object ID == key
semantics)
* fixing of the use of magic numbers such as 0xfefefefe for memory
management purposes (I don't like this aspect of ORBit at all)

One other potential issue I haven't looked at yet in detail, but would
like to, is the object ID / object key scheme used by ORBit and ORBit2.
It's important that transient objects cannot be given keys that repeat
across different process runs. Many (most?) orbit-perl use cases are
mainly as a client with servants typically being transient callback
handlers, where getting called incorrectly could be a problem.

Anyone got anything to add to the above list?

	-Huw