[omniORB] ILU to omniORB (lengthy)

Geoff Gerrietts geoff at gerrietts.net
Fri Sep 26 15:41:12 BST 2003


Quoting Stefan Seefeld (seefeld at sympatico.ca):
> That depends on the types the values can assume, I would think. If
> you can handle the marshalling of your types from/to strings, it
> might indeed be simpler to use string/string pairs. But if you find
> yourself redesigning a type system and complex marshalling
> procedures, it would probably be wise to use existing technologies
> such as CORBA::Any.

Today, everything goes string/string. It's possible string/any would
be more useful to us, or even just any; I can take that gamble, but
I'm wary of it because within the next 18 mos we expect to have java
components talking to this application through CORBA, and relying on a
conversion to-any to produce the from-any result I want seems like a
vulnerability, especially given that omniORB's "any" helpers want to
translate dictionaries into structs.

> I wouldn't ever touch _objref_Interface. It's an type internal to
> omniORB and not supposed to be used by application code directly.
> Relying on it makes your code non-portable. If you really want to
> care for the marshalling yourself, you could use a wrapper class.
> Assuming a 'Worker' class is used that expects typed arguments, you
> can define a 'Caller' interface and implement it by a 'CallerImpl'
> which becomes responsible for the marshalling:

[...]

I'm not as worried about portability as I am about arriving at a
generic approach. I can document around portability problems. Also,
the marshalling I'm doing here is the dictionary -> string/string or
dictionary -> string / any or even dictionary -> any conversion. I
want to do it in one place, because I have some 200k lines of code I
want to change as little of as possible.

I think I can still use your solution -- use composition rather than
inheritance, in effect. I thank you for the insight.

> note that omniidl has a number of options to change the current working
> directory while generating the output, as well as how to lay out the
> generated python files. Try 'omniidl -h -bpython' for details.

Perfect might be a stretch but I think this will give me the solution
I need, if I can figure out how to deploy it cleanly. Thanks again!

I appreciate the rapid and thorough response! It was a lot more than I
expected, and a lot better than I expected, too!

--G.

-- 
Geoff Gerrietts <geoff at gerrietts dot net>      http://www.gerrietts.net/
   "If I were two-faced, would I be wearing this one?" --Abraham Lincoln



More information about the omniORB-list mailing list