Python and CORBA

[Roland Mas]

Samuel A. Falvo II (2000-08-14 20:01:14 -0700) :

> In article <8mol0m$4v5$1 at pegasus.csx.cam.ac.uk>, Duncan Grisby wrote:
> >  PyORBit      -- http://theopenlab.uml.edu/pyorbit/
> 
> In the interests of not being absolutely shocked when things don't work as
> planned, PyORBit, or anything else based on ORBit, do not produce IORs
> capable of being read by any other ORB.  The reason is that they lack an
> IIOP profile in the IOR, which prevents an object from being located via an
> IIOP channel.

I'll have to trust you on that point, since I'm absolutely not sure of
what you mean (in other words, I don't follow you).

> To help make things as fast as possible, Unix domain sockets are
> used exclusively with ORBit, which means that the overhead of TCP/IP
> is eliminated.

  On that point I can speak: you are just plain wrong.  Maybe you
*have been* right about that, but unless there's a way of having Unix
sockets go from one machine to another, I'm doing TCP.  Right Now.
Between three machines.  And it works.  (I'm using ORBit-Python, by
the way).

> And considering the sheer quantity of separate applications (address
> spaces) in a typical Gnome session, it also prevents socket
> descriptor pollution in the kernel.

  You're right here.  But I just discovered that you still have a
certain number of Unix sockets in /tmp/orbit-<login> if you do not
disable Unix sockets in /etc/orbitrc (that's where you activate IIOP,
too -- IP4 and IPv6, although I haven't tried IPv6 yet).  I guess
they're just leftover junk, and that they do not really clobber the
kernel.

> I was bitten by this "bug" (which it isn't really; the CORBA specs
> say nothing about *requiring* an ORB to support IIOP) when trying to
> make a distributed object application that utilized the Gnome
> libraries.
> 
> The other ORBs, as far as I can tell, all support IIOP (I *know* Fnorb
> does, as that's what I ultimately ended up using instead; I use OmniORB
> for my C/C++ stuff).

  Well, I *know* ORBit does, too :-)  And (from the ORBit-Python home
page):

/----
| Also some fairly crude benchmarks of ORBit-Python show that for
| local calls it is around 50 times faster than Fnorb, 6 times faster
| than Java, and only about 50% slower then native C code for ORBit.
\----


> >free for all uses. Both Fnorb and PyORBit seem to have been abandoned.
> 
> I'm on the Fnorb mailing list.  It is still being developed.

  I'm on the ORBit-Python mailing list (and actively posting patches,
too).  ORBit-Python is not abandoned.  I cannot give any positive info
about PyOrbit: there have been about ten messages in the mailing list
for the last four months, one of which answered my search for docs by
something sounding like 'Erm, well, you should have a try with
ORBit-Python instead, you know...'

> However, the maintainers have been assigned other projects by their
> employers.  A new release of Fnorb is currently in the works, but an
> ETA isn't available yet.

  Since I'm heavily involved with ORBit-Python, and since I have
extensive needs about it (Big Project for Real Work), I guess it's not
really going to die right now: whatever I need, I'll code and
contribute to ORBit-Python.

  Just advocating a little bit, and reflecting the truth where it was
mistold :-)

Roland.
-- 
Roland Mas

[...] ou une dent pourrie [...] -- in Variations sur un thème imposé
  -- Signatures à collectionner, série n°2, partie 2/3.