Re: ORBit status?

[David Wragg <dpw doc ic ac uk>]

Miguel de Icaza writes:
 > 
 > > - A robust binary interface specification for object implementations
 > > contained in shared libraries. A kind of in-process equivalent to
 > > GIOP/IIOP.
 > 
 > CORBA supports this already.  ORBit should support it as well.

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.

 > 
 > > - Given the above, a client stub can just be a shared library
 > > containing an object implementation which happens to convert method
 > > calls into on-the-wire GIOP requests, just as DCOM/DSOM do it.
 > 
 > Look in the design specs for ORBit.  At least there used to be a small
 > design document that explained how this would work.

I haven't found anything saying quite that in the ORBit tree. I'm sure 
it was intended - it isn't an original idea.

 > 
 > > - Support for asynchronous object requests, i.e. the out parameters
 > > and return value of a method call get passed to the client using a
 > > callback. 
 > 
 > Also supported by CORBA.  Look for "oneway" in the IDL description.

I was talking about a different thing. This is a language binding
issue, not a core CORBA issue.

Say I have a client application which wants to call a method on an
object which resides on the other side of the internet. This method
_does_ have a return value and/or some out parameters, thus "oneway"
doesn't address the situation (unless I'm missing something).

But if my client app just calls the method (in C or C++, say), it will
block waiting for a reply.

You can contort things using "oneway", so that the remote object
returns the values by invoking another "oneway" method on an object
residing in the client. This is not only more complicated to
implement, but obfuscates the IDL.

What I'm suggesting is a normal CORBA method invocation, with an
asynchronous language binding, e.g. in C:

   someobj_async_somemeth(param1, ..., paramn, my_return_callback);

Which just queues the IIOP request, then returns straightaway. Later
(possibly seconds later) the IIOP reply is recieved and the callback
gets called.

Yes, you can get around this using threads. Threads aren't (yet)
always a perfect solution though, so I think the choice should be offered.

 > 
 > > - Extended language bindings for C. The CORBA C language binding is
 > > pretty awful, compared to Gtk-style object-oriented C. 
 > 
 > The bindings and style share a lot.  Exactly which parts did you
 > dislike?

Superficially they are.

But from the C language binding spec:

  All object references (typed interface references to an object) are
  of the well-known opaque type CORBA_Object. The representation of
  CORBA_Object is a pointer. To permit the programmer to decorate a
  program with typed references, a type with the name of the interface
  is is defined to be a CORBA_Object.

So if you have some IDL:

  interface MyObj {
    ...
  };

A CORBA implentation MUST generate a C header containing:

  typedef CORBA_Object MyObj;

So you can write fun C code like:

  MyObj a;
  CORBA_Object b;

  a = b;
  b = a;

And like:

  CORBA_Object random_objref;

  MyObj_method(random_objref, param1, ..., paramn, env);

Without a murmur at compile time. In other words, there is absolutely
no type safety.

I have some ther quibbles, but that one is a huge flaw. Gtk doesn't
typedef all object pointers to the same type, so it doesn't have this
problem.

--
Dave Wragg