[comp.sys.isis] RPC interface standards and ISIS

rcbc@grimnir.cs.cornell.edu (Robert Cooper) (06/05/90)

There are two issues here:

(1) Compatibility with standards. Programmers that use a standard
such as NDR or XDR will have less to learn when moving to Isis.
Equally, a library or program that uses NDR or XDR will require less
modification to run under Isis if we support these standard(s).
This is the level of support that Ken is proposing. Under his 
proposal, Isis routines like "bcast" would retain their current style with 
a variable number of arguments. There would be a new "printf"-like
option %n that would support NDR.

(2) Compile-time typechecking of remote operations. Ken's proposal
would not achieve typechecking. In particular, with bcast calls it would
still be easy to get the number of arguments wrong, with no help at 
compile time.

Typechecking would be possible to add on top of Ken's scheme using a rather
complicated stub generator.  E.g. a generated stub to perform a multicast
to the entry "FOOBAR" with two input arguments and two results might look
like this:

   int foobar(address *dest, int arg1, char *arg2, 
              int (*process_result)(int result1, char *result2))
   {
      ...define vector a for arguments, vector r for results...
      ...marshal arg1 and arg2 into argument record a...

      n_results = abcast_l("%n", dest, FOOBAR_ENTRY, a, ALL, "%-n", r)
      if (n_results < 0) {
         return(-1);
      }

      for (i = 0; i < n_results; i++) {
         ...unmarshal r[i] into r...
         if ((*process_result)(r.result1, r.result2) == -1) {
            break;
         }
      }
      return(0);
   }

This handles multiple results by a callback method that is common
for implementing "iterators" and "generators" in C, C++ and Modula-2.
It's a sort of "poor-man's higher order functions" approach.

In Cheriton's V system, multicast results were handled in a different
way something like this:

    reply1 = send(groupaddress, ...);
    reply2 = getreply(...);    
    reply3 = getreply(...);
    cancelreplies(...);

This avoids declaring extra procedures just to handle the results.

Yet another solution is a preprocessor which augments the underlying
language with special multicast invocation syntax. This is the
approach taken by the ISA group in their ANSA distributed processing
testbench.  (ISA is an ISO supported standards effort in open distributed
processing.  The ANSA architecture was submitted to OSF.)

Let's get feedback on what people want. Bear in mind that the more
complicated the solution, the less likely we'll implement it any time
soon.

                            -- Robert Cooper