[omniORB] Unicode codesets

[Duncan Grisby]

On Wednesday 17 March, Brett Zimmerman wrote:

> 	I am trying to use omniORB4 in a Unicode solution with the Servant
> running on Solaris and the client running on Windows. From what I
> understand, if I were to use the inbuilt UCS-4 encoding for the
> nativeWCharCodeSet on the Solaris side, and leave the Windows client
> codesets as UTF-16, then the UCS-4 codeset implementation would convert the
> strings to UTF-16. 

Correct.

Unless you are in the very unusual situation of using Unicode
characters outside the UCS-2 range (i.e. character values greater than
65535), you can safely leave the Solaris code set as UTF-16, since
UTF-16 code points are all the same as UCS-4.

> >From the manual - 9.3 Implementing new code sets:
> 'If the transmission code set does not know how to handle the native code
> set, it converts the string/wstring into UTF-16, and passes that to the
> native code set object (or vice-versa). All code set implementations must
> therefore know how to convert to and from UTF-16.'
> Am I interpreting this correctly? 

I don't know how you're interpreting it, but it's not relevant to you
since you're not implementing a code set. You're just using code sets
that come as part of omniORB.

> A call to proxyPushConsumer->obtain_subscription_types() from the windows
> client in generating the following trace:
> omniORB: throw UNKNOWN from GIOP_C.cc:241 (NO,UNKNOWN_UserException)
> with the following exception being thrown further along:
> omniORB: throw MARSHAL from cs-8bit.cc:361
> (YES,MARSHAL_StringNotEndWithNull)

Neither of those exceptions look like they have anything to do with
wstring.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --