Python, CORBA, and Borland Java interop?

[Dave Benjamin]

martin at v.loewis.de (Martin v. Loewis) wrote in message news:<m3k7kpmsim.fsf at mira.informatik.hu-berlin.de>...
> If you can impose restrictions on the expressiveness of the IDL you
> need to support, then it should be possible to add valuetypes to any
> of the ORBs in reasonable time. For example, if you only need
> StringValue/WStringValue, then implementing this as a special case.

I must admit that my familiarity with CORBA is not extensive, and the
IDL features you describe may or may not be necessary. So far, the
problem has been with WStringValue.

The release notes for VisiBroker for Java 4.0 are here:
http://info.borland.com/techpubs/visibroker/visibroker4/vbjrel.html

They indicate that the latest version of their IDL compiler supports
"abstract, custom, factory, native, private, public, supports,
truncatable, valuetype, and ValueBase.". This is not to say that their
java2idl utility uses all of these features within its exported IDL
code, only that we cannot rule them out until we have more experience
and understanding of AppServer's IDL interface.

> I'm most familiar with Fnorb these days; I'd invite you to post
> details of your requirements (only value boxes or true value types,
> inheritance or not, truncation or not, support for cyclic structures
> or not, what to do about methods, etc.).

Fnorb was the first ORB I tried. It was unable to deal with the
following types of IDL statements:

 - valuetype WStringValue wstring;
 - #pragma ID detailMessage
"RMI:java.lang.Throwable/detailMessage:0000000000000000"

Is there a way we could perhaps preprocess the IDL into something
Fnorb can understand that will allow us to pass strings from Java? You
mentioned that this could be a "special case". If we could get over
this initial hurdle, we could at least call simple methods on the
server. Right now the string issue is holding us back.

> I also seem to recall that omniORBpy has made progress in the area of
> valuetypes, so you may want to check the latest version.

Their web site seemed to indicate that valuetype support was working
with the 4.0.x releases of omniORB. However, when I tried to parse the
IDL files, omniORB complained about valuetype support. I tried this
with omniORB 4.0.0, which seemed to be the latest version available on
sourceforge:

http://sourceforge.net/project/showfiles.php?group_id=51138

Is there a different version that I should have tried?

Thanks for the help!
Dave