[coyotos-dev] [CapROS-devel] CapIDL design issue -- return codes

[Jonathan S. Shapiro]

On Sat, 2007-07-07 at 23:29 +0100, David Hopwood wrote:
> > Questions:
> > 
> >   1. Is it important to be consistent with other IDL systems?
> 
> IMHO, no.

While my personal preferences match David's, let me argue the other way
for a moment.

There is a very large body of C code -- primarily the GNOME code and the
Mozilla code -- that are built around CORBA or CORBA-like IDL. Some of
this is code that we would like to be able to adapt into a capability
framework, and some of the key developers may be interested in that
adaptation.

In *every* CORBA IDL compiler that I have checked, the return value
stated in the IDL is the return value given to the corresponding C
procedure. The problem with the "return the result code" convention is
that we lose the ability to "plug and play" with that existing body of
code.

Today, there are two sources of incompatibility: CapIDL input syntax
does not quite match CORBA input syntax, and CapIDL output conventions
do not match the conventions of C bindings.

The IDL source compatibility issue is fairly straightforward to deal
with; we could implement a CORBA-compatible front end without much
difficulty, because the current syntax is derived from CORBA except
where MarkM and I simply could not stomach it. In many cases I now think
that we were wrong; compatibility really was more important than our
aesthetics.

The source level mapping difficulty is more complicated. It is simply
not realistic to expect that the large body of existing GNOME and
Mozilla code will get rewritten (not even if they agree with us that
returning error codes was a better way to go). There are two ways to
approach this issue:

  1. Adopt a compatible binding strategy now.

  2. Take the view that we should adapt the GNOME IDL compiler to
     generate a transport-compatible mapping, leaving it's surface
     syntax in place, but incompatible with general conventions.

     The problem with this will be procedures that return capabilities,
     but existing IDL input doesn't do this (because it cannot).

  3. Since CapIDL client procedures are inlined anyway, take the view
     that we can emit stubs either way at need, and that we are merely
     choosing the preferred convention. We can switch to the other
     strategy for applications that need it, and do something wonky
     when capabilities must be returned (on the theory that existing
     interfaces won't be doing that in any case).

shap
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC