[coyotos-dev] [CapROS-devel] Position statement on IDL bindings

[Charles Landau]

At 9:14 PM -0400 7/7/07, Jonathan S. Shapiro wrote:
>So here is my final outcome on all of this:

Gee, I was on vacation and missed this whole discussion. Fortunately, 
I generally agree with shap's conclusions.

>1. For languages that have native exception handling, ...
>
>    In the case of procedures returning capabilities, the preferred
>    implementation will be one of the following:
>
>      A. Rotate the return value to the end of the parameter list
>         as an OUT parameter and change the return type to void.
>
>         This is an appropriate simple implementation for C++, for
>         example.
>
>      B. Provide a means, possibly through the IdlEnvironment mechanism
>         to "allocate" an appropriate location for the return capability.
>
>         In this type of binding, the location can be "allocated"
>         before the call, and the encapsulating language object can
>         then be returned as the return value.
>
>    Which solution is appropriate is highly language dependent. In a
>    GC'd language, for example, the approach of allocating locations
>    is probably preferred. In C++, it is possible to imagine an
>    encapsulating template that uses reference counting on capability
>    locations.

Doesn't the caller have to allocate a slot to receive the capability 
in *either* case?

>2. For languages that do NOT have native exception handling, IDL
>    result codes should be returned by the stub, and the nominal return
>    type (if not void) should be rotated to the end of the parameter
>    list.

Good. IIUC this is not a change from the current CapROS IDL compiler.