Path: utzoo!utgpu!watserv1!watmath!att!ucbvax!tut.cis.ohio-state.edu!mailrus!cornell!ken
From: ken@gvax.cs.cornell.edu (Ken Birman)
Newsgroups: comp.sys.isis
Subject: Re: OSFdecision to use Decorum
Message-ID: <41690@cornell.UUCP>
Date: 4 Jun 90 00:52:26 GMT
References: <65@decvax.decvax.dec.com.UUCP> <6110003@hp-ses.SDE.HP.COM>
Sender: nobody@cornell.UUCP
Reply-To: ken@gvax.cs.cornell.edu (Ken Birman)
Organization: Cornell Univ. CS Dept, Ithaca NY
Lines: 29

In article <6110003@hp-ses.SDE.HP.COM>
  wunder@hp-ses.SDE.HP.COM (Walter Underwood) writes:
>It would be nice to see Isis using NDR and a stub generator instead of
>the printf-like specs.  That would allow specifications for Isis
>services (or are they dialogues?), and compile-time checking for the
>formats.
>

I agree; this would be a nice improvement.  My inclination would be to
support a %n format type, though, and perhaps a %x format for those
of you who are fond of XDR.

My difficulty with stub generation has always related to the way that
multiple replies are returned.  One recent idea was to allow the 
sender of a broadcast to supply a "collator" function; it would be
called on each received reply and would indicate if it wants ISIS to
wait for "more replies".  Another possibility is to imbed this in the
function call itself; I recently saw a language spec for a system
called FLAME (Mehdi Jazayeri of hplabs was the first author) and it
adopts this approach.  A third approach is the one that Marc Shapiro
uses in SOS, with stubs that are actually defined as part of the service
(part of its interface, in fact) and hence can include some fairly 
fancy logic...

Assuming that we went with the first ("callback") style of reply collection,
would this and a %n format permit reasonable stub generation for process-group
based services?

Ken