> "Daan Leijen" <[EMAIL PROTECTED]> wrote,
>
> > Sigbjorn Finne has done a lot of work to make sure that H/Direct can
handle
> > any standard and dialect of IDL that is around, including
> > OMG/Corba IDL's. H/Direct can generate interface code to
> > any C library that is described with IDL (which is
> > normally just adding some attributes to the C header file)
> [...]
> > Secondly, it is quite easy to extend H/Direct to support
> > other protocols (like GNOME).
"Manuel M. T. Chakravarty" <[EMAIL PROTECTED]> wrote,
> I know that and how H/Direct supports...I don't dare to say
> it...COM and plain C. However, what I am unclear about is
> how does it support OMG's CORBA IDL? As you mention in the
> H/Direct paper, COM fixes a language-independent, binary
> interface, but CORBA IDL doesn't do that. Did you define a
> CORBA language mapping for Haskell?
Hi Manuel,
Unfortunately, there is more than one IDL around, they all look
the same and can basically express the same things.
Fortunately, H/Direct can get its input from both OMG /CORBA and
MS dialect IDL and extract the right semantic information.
In a sense, it doesn't matter in what language you describe your
interface as long as it gives enough information to generate marshalling
code. (that's why it is possible to even use C header files, allthough you
need some heuristics and/or extra directives, as you show in your paper).
We have not defined a CORBA *mapping* however. C and COM are
specific protocols for which we defined a mapping and generate marshall
code.
To *specify* an interface in C or COM, you can use any sort of IDL,
including OMG/CORBA IDL.
(btw. since the 'C' binding is actually a (dynamic or static) library
binding, it
supports also languages like pascal, fortran and many others with standard
calling conventions (cdecl, pascal, stdcall, fastcall,...))
The bad thing is that Corba is not a binary protocol and thus H/Direct needs
a different backend/mapping for each different Corba vendor. Many languages
provide
a Corba binding by providing their own Corba environment and interacting
with other Corba environments via the IIOP (internet) protocol of Corba
which
*is* a binary standard.
(Things are not really that bad since it seems that vendors start to
standarize on
object layout).
> If not, how can you
> support CORBA? To support GNOME, the next step is to
> support the binary interface defined by ORBit (GNOME's
> Object Request Broker). I guess that this means tweaking
> the marshaling code generation. This you think is easy?
Supporting Corba would be a lot harder as said above. One approach could be
to just support one environment, I can't recall the name but there is one
excellent
free implementation around of corba (minicorba or something ?)
Supporting Orbit however seems quite easy and it would be very cool to have
around, allowing for a comparison between COM and ORBit.
You should contact Sigbjorn Finne on the exact details but if
ORBit looks like COM (which is probably true) than it wouldn't
too much work.
> (I'd be really interested to get some more information about
> this, because, as I mentioned, I am interested in adding
> such support.)
It would be very nice to have someone adding these features to
H/Direct, especially since you are working with big frameworks
like GTK. This would have been a nice test of H/Directs abilities
and in a sense it is disappointing to learn that H/Direct didn't fit
your needs completely. I hope to learn how H/Direct can be improved
to take away the need for yet another FFI, which was our primary motivation
for building H/Direct.
All the best,
Daan.
> All the best,
> Manuel
>
