Re: interface generator

[Nick Ingolia <ingolia@mit.edu>]

-----BEGIN PGP SIGNED MESSAGE-----

Hello...

Richard Godard <richard.godard@tecfa.unige.ch> wrote:

> At the cost of a little overhead, couldn't the interface generator/RPC
> system be just 'another package'?

One possible would make each entire interface generated by the
interface generator a "package" with a single type of message.  The
other alternative is a design in which RPC is a package and various
interfaces deal with one end of RPC.  To quote from a message
with an excellent example,

Michael Brundage <brundage@ipac.caltech.edu> wrote:

> #$#edit-set-verb-code code="..."
> might happen to be equivalent to
> #$#rpc-invoke object="editor" method="set_verb_code" args="..."

Two things favor the former design:

* It allows existing version negotiation code to negotiate the
versions of individual RPC-based packages rather than using a seperate
version negotiation system in the RPC layer.  Different versions of
the same RPC-based interface will have different sets of functions and
function prototypes, meaning that they cannot necessarily communicate
properly.

* When generated RPC interfaces are working beneath an existing MCP
implementation, it allows multiple generated interfaces to operate
completely independent of one another and not necessarily knowing of
each other's existence.  

In favor of the latter design:

* Version "negotiation" for RPC-based packages may have very different
needs than version negotiation for "lower-level" packages based only
in MCP.  For instance, in most cases it would be muh easier to deal
with an older version of an MCP interface and much more difficult to
deal with different versions of a RPC generated interface.  In the
latter case, the format of various messages is "tied down" in function
prototypes, whereas in the former the keyword/value pairs represent a
much "looser" format.  

* If done properly, the RPC package top-level dispatch function (i.e.,
the function responsible for accepting incoming MCP messages for the
RPC package) could obviate any direct interface between RPC-based
interfaces and the top-level MCP dispatch function.  It could also get
rid of a bit of redundant code which might otherwise need to be put
into each interface.

I am not certain at this point which would be better, but I'm favoring
the latter.  I would welcome input from anyone who has other points
for or against either design, particularly anyone who has implemented
MCP and believes that one or the other would be much easier to fit
into an existing implementation.

Also, as I have mentioned before, I am going to restrict the domain of
the interface generator to fairly MOO-specific data types.  I am also
going to try to make it fairly straightforward to use; particularly, I
am currently considering permitting only synchronous return values
(call and wait) or asynchronous returnless functions (call and
forget).  Finally, the data types I am planning to deal with in the
interface generator are: 

* integers on the range