Python and CORBA

[Christopher Browne]

Centuries ago, Nostradamus foresaw a time when Samuel A. Falvo II would say:
>In article <877l9jjhpv.fsf at cachemir.echo-net.net>, Roland Mas wrote:
>>> 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).
>
>An "object reference" in CORBA contains one or more things call "Profiles."
>These profiles tell the CORBA ORB where to *find* the object to which it
>refers.  For example, if someone were to make a CORBA ORB that used SOAP as
>its remote procedure call format, a web URL would be one of the profiles
>that sits inside the object reference.
>
>Object references are externalized to files using plain ASCII.  They start
>with "IOR:" followed by a bunch of hexadecimal digits.  These digits are
>read in by CORBA ORBs when you call the ORB::string_to_object method.

Right.

>>  On that point I can speak: you are just plain wrong.  Maybe you
>
>No, *I* am not wrong -- the folks who work on GNOME are wrong,
>apparently; see below.  ;)

I'd count it "controversial."

The folks working on GNOME have made a particular "design preference,"
by default, to mandate a particular authentication approach when GNOME
apps export functionality via CORBA.

On the one hand, this "preference" is indeed not standard, which may
be argued to be a Bad Thing.

On the other hand, this "preference" should do a reasonably good job
of preventing security breaches without needing to do a whole lot of
security configuration, and when MOST users of GNOME are likely to be
relatively naive, from a security standpoint.

>>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
>
>THANK YOU!  THANK YOU!  <8~-D  I have talked to no less than about 10 people
>about this, in both #gtk+ and in #gnome (nobody on the mailing lists at all
>responded to my questions), and *nobody* has ever told me that.  :)

An forthcoming book (it's at the printers...) with which I'm
associated has a section that discusses this matter...  Yes, edit
/etc/orbitrc as needed...

I've tried IPv6, and all I get is segmentation faults, so I think that
one Isn't There Yet...

>If this works, I'll gladly and proudly stand corrected!  :)  If it doesn't,
>do you mind if I private e-mail you for additional assistance?  (Note that I
>work primarily with C for ORBit, since Fnorb is already set up for my Python
>CORBA stuff.)

I rather like orbit-python; it would be nicest for it to be "maximally
compliant with the ``standard'' mapping," although my priority is for
it to work well...

>>| 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.
>
>Well, ORBit itself is honkin' fast too.  Don't forget that good algorithms
>is the single best way to "optimize" something significantly.

Indeed.  If you tune ORBit a bit, that potentially can help _anything_
that depends on it...

>>  Just advocating a little bit, and reflecting the truth where it was
>>mistold :-)
>
>I just wish someone had done this about six months ago, when I was trying to
>figure out why, exactly, none of my code was working via TCP/IP... :)

Indeed.  It took me a couple days to figure it out, including sending
a note to "sopwith."
-- 
(concatenate 'string "cbbrowne" "@" "ntlug.org")
<http://www.hex.net/~cbbrowne/corba.html>
"A train stops at  a train station, a bus stops at  a bus station.  On
my desk I have a work station..."