[omniORB] omiORBpy, pickles and strings

[Duncan Grisby]

On Tuesday 3 October, Gary Pennington wrote:

> I can't just return a string, since the string may contain NULL values
> and language mappings for all languages don't allow NULLS in strings out
> of respect to C/C++. So instead, I shall declare the data to be a
> sequence of octets ( or should I declare it some other way?).

Yes, sequence<octet> is the right thing to use. Apart from the
problems with nulls, future versions of omniORB may well try to
transform strings into different character sets, which would be very
bad for your purposes.

> 2. If I have an interface that declares the following :-
> 
>   typedef sequence<octet> octetSeq;
>   Blah blah blah...
>   octetSeq getState(in UserIF agent);
> 
> Why do I get a string in a cPython client, whereas jPython behaves
> correctly and delivers up a pyArray of ints?

Actually, the CPython version (using omniORBpy) is the correct
one. The Python CORBA mapping says that sequences and arrays of octets
map to strings. This is because strings are much faster than Python
lists. (Sequences and arrays of char also map to Python string.)

That explains why the server doesn't complain when you try to return a
string -- that is the correct mapping. It _would_ complain if you
tried to return a list.

> 3. Should I be declaring my interface to return Any and casting down on
> the client end to a string?

"Casting" is not a meaningful concept in Python. Regardless as to
whether a value is inside an Any or not, it follows the Python mapping
rules. You can't subvert the Python type system with Anys.

Your problem is that you are trying to use the CORBA to Java mapping
though JPython's Java to Python mapping. The result is not the same as
the direct CORBA to Python mapping. In the absence of a proper
implementation of the CORBA to Python mapping for JPython, you'll just
have to live with the differences.

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --