Re: ORBit status?

[Owen Taylor <otaylor gtk org>]

Tom Tromey <tromey@cygnus.com> writes:

> >> Huh? CORBA doesn't explicitly support it (unless it's part of some
> >> auxiliary CORBA document I haven't seen yet). Sure, you can pick
> >> one of the language bindings, for instance the C language bindings,
> >> and decide that the binary interface will be that + the standard C
> >> calling conventions for the system. I don't consider that a good
> >> decision: I'd explain the reasons why, but I'm not sure this is
> >> what you mean.
> 
> Miguel> At least the CORBA document I have here (corba-98-02-01.pdf)
> Miguel> in section 2.2 (Example ORBs) talks about this specific case
> Miguel> (2.2.4).
> 
> Yeah.
> 
> I'd still like to hear David's proposal.  I don't think anything is
> really wrong with using the standard ("C") ABI for a system, but I'm
> willing to listen to alternate proposals.

I'm not really sure what is being discussed here. The standard C
language binding is probably the right thing to use when binding
to C. If the idea is to use that interface for binding to other
(interpreted) languages, then, as someone who has written such
bindings, I must say I find the idea somewhat appalling.

To explain - an interpreted language binding that requires you to
generate stubs in C and compile them for each new interface would
be barely worth the bother.

At a minimum, the stubs that a a binding for language X uses
should be in language X. (Making calls to a X to C API). I'm
personally fond of a stubless approach - the language binding
does the translation on the fly using information from the
interface repository.

What is required to support these sorts of bindings is an
interface for (un)marshaling types. Functions like:

 marshal_long (Buffer *buffer, COBRA_long l);

(and so forth). 

A large part of Flick supposed speed advantage is avoiding using
these sort of functions from the stubs, but a complete system
needs them anyways to do things like C language Anys.

[ 
 An alternative is the DII/DSI/DynAny specification of the
 OMG. But that imposes a considerable amount of overhead, so I
 think a more direct backdoor to the underlying functionality
 should at least be provided.  (Using a direct marshal-unmarshal
 interface is no more complicated than using DSI/DynAny, though it
 is in theory less portable)
]

The way this would fit in with shared library activation is a "in
memory" transport. The language X binding writes the information
to a buffer, the buffer is passed to the C implementation of the
object that lives in the shared library, and the C implementation
unmarshals from the buffer. Clearly there is some extra overhead
here, but the benefit is flexibility.

Regards,
                                        Owen