[omniORB] Omniidl backends

[Karl Waclawek]

Since you replied 3 times, I *must* write
an answer, however, I leave it at one. :-)

> On Tuesday 10 September, "Karl Waclawek" wrote:
> 
> > I a  new to Omniorb and curious about the IDL compiler:
> > 
> > It seems that the language specific part of it is implemented
> > in Python through a defined interface using the visitor pattern.
> 
> Yes.
> 
> > That suggests that - in theory - one could build
> > Python modules that generate code for other languages.
> 
> Yes, but it's not a trivial thing.

That's what I thought.
 
> > How can the Dlls, like for instance OmniOrb400_rt.dll,
> > be accessed. Only from C++? Or do they have a C-style interface.
> > That might make it possible to access them from other
> > languages without writing an extra binding in C++.
> 
> I recommend you look at omniORBpy, which is the version of omniORB for
> Python. It does exactly what you are suggesting -- it has a back-end
> for omniidl that outputs Python code, and a module written in C++ that
> provides a Python interface to the facilities of the C++ ORB library.
> As you'll see, there's quite a lot to it.
> 
> What language are you wanting to use?

Delphi/Object Pascal.
The reason I asked was that, if your Dlls were
exposing everything in C-style, one would not
need to write an extra binding, since Delphi can
interface to such Dlls directly.

A second approach might work if *everything*
in the OmniORB Dlls was exposed as abstract (pure virtual)
classes. Since the VMT layout of most C++ compilers
for such classes (at least on Windows) is pretty much
identical (for reasons of COM compatibility), that
would again have been a possibility, because Delphi
can access such VMTs (but it's not really easy to do).

I had a look at your Python bindings, and yes, it's
quite some work.

I have been pointed to ORBit as an ORB with
a C binding, and I will give it a try.
However, at a first glance, it does not look
as mature as OmniORB. 

Thanks for the reply,

Karl