Re: ORBit status?

[David Wragg <dpw doc ic ac uk>]

Owen Taylor <otaylor@gtk.org> writes:
> 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.

I object principally to its lack of compile-time type safety. The C++
bindings have this, as do the Java bindings, so I expect the C
bindings to as well.

Of course, strict CORBA C bindings should be offered as well.

> 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.

Agreed. The C bindings aren't on their own sufficient for this anyway:
there needs at least to be a mechanism for dispatching method calls to
the object implementations.

> 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.

For the end-programmer, generating and compiling the stubs (in
whatever language/s) is not a particularly onerous task relative the
writing the code that actually does something with those stubs.

And with DII/DSI, CORBA doesn't force you to use the stubs if you
don't want to - in any language. (As you note, there's significant
overhead.)

Bear in mind that that an in-process object request between languages
X and Y can be done much more cheaply than by marshalling the request
in X, unmarshalling in Y and vice versa with the reply. Between
certain languages, e.g. C and C++ this can be done almost as cheaply
as a C++ virtual function call. Low overheads, while still allowing
distribution, has been a major part of the hype of COM and SOM. You
may consider 

> 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).

But where do you put the dividing line between the stubs in X and the
common part in C? If it is towards the side of X (i.e. the stubs in X
are as small as possible, just passing everything through to C, which
then does things like marshalling to GIOP in the remote case), you can
get CORBA bindings for X up and running relatively easily, and this
approach will always be fairly easily.

The other approach is to do lots more in the stubs in X, including
things like GIOP marshalling. In an extreme case you write the whole
ORB in X and ditch C. These approaches may be "truer" to X, and can
make life a bit more straightforward for the X programmer. However,
they might take more work.

I'm interested in CORBA bindings for C, ObjC, Guile, and I'd like to
facilitate bindings for Tcl and Perl (though I have no desire to use
those last two myself). So the former approach, where more is shared
between lanuages, appeals to me.

In all approaches using stubs, the effort needed tends to (number of
languages) * (number of object interfaces). I'm sure there is a lot of
room for debate about how the constants in there measure up for the
various approaches.

> I'm
> personally fond of a stubless approach - the language binding
> does the translation on the fly using information from the
> interface repository.

In interpreted languages that have enough type information at run-time
to do this (i.e. scripting languages), it is an interesting
approach. Compiled language don't generally let you dynamically create
procedures/methods of arbitrary types. Java being the major exception,
of course.

Just-in-time compilation of stubs is also a possibility, but I'm not
sure it would ever be much of a win.

> 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.

Sure, you need an engine that does mashalling for the
DII/DSI/Anys. That doesn't mean that there shouldn't be a more
streamlined mechanism when Anys aren't involved.

The contribution of Flick, IMHO, is that it applies compiler
technology to the process of generating stub, which has previously
been seen as a fairly trivial mapping from the IDL (similar to the
state of programming language compiler technology 30-40 years ago).

> [ 
>  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)
> ]

Well, a language binding doesn't have to follow the IDL definitions
for the dynamic invocation pseudo-objects. The OMG-specified language
bindings assume that if you're worried about overheads you'll use the
stubs.
 
> 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.

But in the case of shared library activation, you can streamline
things until you're doing something very close to C++ virtual function
invocation. Look ma, no marshalling.

--
Dave Wragg