Re: my "0.4.4" patch (was Re: Does CORBA::ORBIT place any constraints on the IIOP?)

[Owen Taylor <otaylor redhat com>]

[ resending to the list, since it the list address was wrong the first time ]

Huw Rogers <count0 building2 co jp> writes:

> The problem with ORBit is that as far as I can tell it's almost entirely
> used by Linux/x86 developers, mostly involved with the Gnome project, in
> software where it only talks to itself and not to other ORBs. This is
> compounded by the fact that all new work is going on in ORBit2, which is
> even less well tested for interoperability than ORBit stable, and
> doesn't work with orbit-perl anyway.
> 
> I would propose a binding to omniORB instead, which is a much more
> widely used ORB, but that would involve adding a C++ runtime to the perl
> module and I am not sure of the consequences of that across platforms.

A binding to omniORB is a different project, and not orbit-perl. :-)
Since orbit-perl is my third ORB/Perl binding (the first two being
ORBit and MICO), doing another one not something I can discourage
someone from doing with a straight face. But if I was still working on
CORBA and Perl, I don't think I would be moving on to yet-another-orb
just yet.

The virtues of ORBit are:

 - standard ORB of GNOME, so very widely deployed
 - lightweight, and simple, so easy to bind to.
 - fast (was ~10x faster than MICO when I started)

The main disadvantage is that ORBit has never been CORBA for 
CORBA's sake, and thus tracking the latest extensions of the 
OMG has never been a high priority. Also that distributed
applications are not a primary target of ORBit, so some
of the features needed there have been a lower priority.

ORBit is certainly very much used beyond both Linux and x86 
(it was developed largely on an Alpha) though it *is* tied
fairly closely to Unix-like systems.

I think these advantages and disadvantages pretty much
apply to ORBit2 as well these days.

ORBit2 has various features that should (though I've not looked at
them in anything approaching detail) make writing a dynamic binding
like ORBit Perl easier.

The marshalling code in CORBA::ORBit would probably need
rewriting for ORBit2, but I'd suspect the IDL parser, the general 
framework, and the interfaces to the POA and related
objects would cary over. As well, as the binding itself,
the test cases, etc.

Using C++ along with Perl in CORBA::MICO certainly made things 
a bit more challenging .. marshalling exceptions was tricky
and there were various odd things with the Perl bindings.
But nothing fundemntally impossible to overcome.

If you do want to start a binding for OmniORB, feel free to "steal' 
as much code and structural inspiration as you want from CORBA::MICO 
and CORBA::ORBit, and certainly I'd hope you'd use the
same language binding as CORBA::ORBit, since that's the part of 
CORBA::ORBit I'm most proud of.

Just don't call it CORBA::ORBit, since that would be, hmmm,
confusing.

Regards,
                                        Owen