Re: ORBit status?

[Owen Taylor <otaylor gtk org>]

[ Please direct replies only to gnome-components-list ]

David Wragg <dpw@doc.ic.ac.uk> writes:

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

The lack of inheritance in C fairly well prohibits this. 
GTK+ gives (optional) run time checking through its cast 
macros:

 gtk_label_set (GTK_LABEL (label), "new text");

If you wrote:

 gtk_label_set (GTK_LABEL (entry), "new text");

That wouldn't be caught until run time.

The general reasons why I see the CORBA C bindings as clumsier
than working with GTK+ OO programming are the exceptions (no
way around if you want exceptions), and the lack of a good
data-structures library like GLIB.

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

Well, there is a detailed dispatching method specified in
the C binding. For langauges bindings with compiled stubs (C++,
ObjC) could in theory be based on that.

I think the DSI setup for dynamic implementations would be a
reasonable start for a generic dispatching mechanism - I would just
add extra operations to the ServerRequest to allow direct 
marshalling without going through Any's.

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

That depends how good the language binding is ;-).
 
> 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.)

Using DSI/DII is pretty ugly in C or C++.  In the MICO/Perl binding,
"dynamic" invocation is completely transparent to the end user.
 
> 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 

You only get that benefit on a (n_languages)**2 basis. If you want to
communicate between arbitary languages X and Y, then you need an
intermediate form. The marshalled form of the buffer is not an
unreasonable one.
 
> > 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.

In general, the programmer using the binding won't see a difference
between these approaches. The difference really lies more for
the implementor - whether the implementor would rather write
in language X, or in the C API for language X. The pure-X approach
though means that you lose the ability to do interlanguage
communication in a single process space. (And, means that there
is a lot of duplication)

> 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 don't understand how the number of object interfaces factors
into this. Once you have the stubber code and the API for one
language, implementing each object interface is a matter
for the application.

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

I think you mean "generation" not "compilation". A cached-stub
approach where the user 'includes' the IDL file, then the language
binding generates the stubs if they don't already exist, is
certainly a possibility for some languages. 

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

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

There is a lot of hype in the Flick documention as well as some
truth. I think you'd find that good commericial IDL compilers (like
Visigenic) already do a lot of what Flick does. GIOP was carefully
designed to allow an IDL compiler to optimize marshalling, so it is
sort of silly to say that nobody ever thought of it before.
 
> > [ 
> >  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.

I think you are confusing things:

 - The way a language binding is implemented. (Possibily on to
   of DII/DSI, possibibly using API extensions)

 - The way a language binding itself does DII. (Possibly using
   Pseudo-objects, like C, C++, possibily just using the language
   syntax to invoke the operations)

In C or C++, programmers will prefer stubs largely because
of ease-of-use.

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

Only if you are going C++ to C++ or C to C, or maybe C++ to C.  And
even then you have to worry about the fact that POA compliance doesn't
really allow complete short-circuiting of the ORB. (See section
9.2.10 of the CORBA specification). You can avoid marshalling, you
can't avoid going through the ORB.

Regards,
                                        Owen