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

[Owen Taylor <otaylor redhat com>]

Huw Rogers <count0 building2 co jp> writes:

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

The "reliable / interoperable" problems were, I believe, just 
a sign of early code. I haven't really followed ORBit2 in detail,
so I can't really comment on where it is going. 

There are some fundamental problems with ORBit-0.5 that affect the
Perl bindings; for example, while orbit-perl carefully checks all
parameters it demarshals, there is no checking on parameters that are
demarshalled by the ORBit code, like typecodes and object references.

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

I think you should assume that ORBit2 will eventually replace ORBit ..
GNOME-2.0 uses ORBit2, not ORBIt,. GNOME-2.0 deployments will be
replacing GNOME-1.4 deployments, and as that happens ORBit2 will
replace ORBit.

I'd guess that orbit-perl is using most of the code in src/orb and
src/IIOP in the ORBit2 distribution ... so say 15,000 to 20,000 lines
of code. Plus all of libIDL, about another 20,000 lines of code. Not
an enormous amount of code, especially if it's not changing; but
orbit-perl is only about 7000 lines of code in total.

Plus you wouldn't get any bug fixes, testing, etc, from users
using other language bindings.

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

The difference between ORBit2 and ORBit from C in this area is
basically the same as the difference between orbit-perl and
ORBit.. ORBit2 uses typecode information instead of compiled stubs and
does checking, just like orbit-perl, while ORBit1 used huge compiled
stubs and did no checking.

If using ORBit2 from Perl involves a double-walk through the typecode
information, then there will be a performance hit, but if that's
the case, then the ORBit2 language binding interfaces just need to
be fixed to allow more direct access to the output stream.

(The ultimate arbitrer in questions of performance is benchmarks :-)

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

The way ORBit handles this is to allow arbitrary reentrancy - whenever
an outgoing call is blocking, calls can come in. Many of us feel that
this is a somewhat dangerous model, though slightly less dangerous
with refcounted memory management than it is in C.

> * 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.
 
ORBit (including the current ORBit) uses the object key as it's primary 
security mechanism... the object keys are chosen to be unguessable
(implementing this is a bit of a performance problem in some cases),
so they also should be non-repeating.

> Anyone got anything to add to the above list?

Sounds like a reasonable list, and like it will keep you busy for
a while. Good luck! :-)

Regards,
                                        Owen