[omniORB-dev] omniORBpy and an Interface Repository

[Duncan Grisby]

On Wednesday 17 September, "Kevin Wooten" wrote:

> Does CORBA have a spec. for getting IDL definitions from an interface
> repository?

No. Various things related to DII and DSI talk about it, but not in a
way that's useful to you, I think.

>    I am interested in the ability for omniORBpy to connect to
> an IR and "download" some definitions to use. I know it does not support
> that natively but I am going to add something like it. I am just
> gathering input and wondering if OMG has already thought of this (since
> I am not very familiar with the myriad of specs they have).
> 
> As far as implementation goes; would the best way be to copy, or use,
> the omniORBpy's dynamic compilation to get definitions into a running
> system?

The way omniORB.importIDL works is to fork omniidl, and dynamically
import its output.

I can think of three ways to implement what you want:

 1. generate IDL from the contents of the IfR, then import it with
    importIDL().

 2. generate suitable Python code, equivalent to that created by
    omniidl, and import that.

 3. dynamically build Python classes and data structures (mainly type
    descriptor tuples) directly, rather than generating strings.

Option 1 would be by far the easiest, since it's well defined what the
output should be, and the output is relatively simple. It would also
be useful beyond your application of dynamically importing into
Python. On the other hand, it would be far less efficient than the
others.

Options 2 and 3 would probably be about equivalent in difficulty. They
are harder because the objects you need to build (either as text for
option 2 or objects for option 3) are not specified anywhere. You
would have to figure out what was needed by analysing the Python
back-end and C++ marshalling code. Both, especially option 3, would be
significantly quicker to execute than generating IDL.

Having said all that, what do you actually want this for?  For almost
all uses, the programmer writing the code using the CORBA definitions
must know what the IDL says, so you might as well have the IDL, and
compile it as usual. The common things that really do need dynamic
behaviour, like object browsers, would probably be better off with a
DII like approach, rather than generation of normal Python things.

Cheers,

Duncan.

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