[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