[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: interface generator



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

> You can also use a compiler in this context to create a server stub
> that performs RPC calls to the client object (or vice-versa); for
> example, the client could construct a MOO object $client_editor, and
> then calls to verbs on this such as
> $client_editor:set_verb_code(...)  would be translated into RPC
> calls and sent to the client to be executed on the remote editor
> object in the client.  Of course, the same thing can be accomplished
> through a dedicated #$#edit message system.

This is essentially the design I had been considering.  It would add
a significant layer of abstraction away from MCP itself, allowing
application designers to write code which, rather than ever dealing
with MCP explicitly, simply call procedures/functions/verbs/methods
whose arguments are collected into an MCP message, transported to the
other connection endpoint, translated into the language-specific
representation for that endpoint, and the procedure on the other
endpoint is executed there.  The return value is collected into an MCP
message, transported to the procedure caller's endpoint, translated
into the language-specific representation on that endpoint, and
returned as the return value of the procedure.  

The intent is to provide application designers with an interface
removing any need to deal with the construction or parsing of MCP
messages or with the translation of data between an MCP representation
and the various language and platform-specific representation in which
it is expressed by the calling procedure and executing procedures.

The RPC stubs created would be designed with an API such that they
could parse raw MCP lines for one or more RPC-based packages and
de-multiplex them for distribution to various RPC-based (or other)
packages.  Independent of this initial de-multiplexing step, each RPC
package would have a procedure dispatch function which received raw
MCP lines solely for the package in question.  It would extract the
procedure name and arguments from the message, when necessary
translate the arguments into system-specific representations, and call
the user-provided function.  When the user-provided function had
completed, it would collect the return value and construct a line or
lines with which to return to the server.

Every effort would be made to insure that the stubs could be used in a
"stand-alone" fashion with little work or could be integrated into an
existing MCP-based application.  That is, the interface generator will
have a (probably relativly slow and inefficient) parser
as well as the ability to accept pre-parsed MCP lines.  

Also, I should point out that I have certain feelings towards
languages which would almost certainly color any such system I design.
The languages with which I have worked most extensively and to which I
would likely provide interfaces are, in addition to MOO, C and Scheme.
I feel that any implementation capable of being translated into
interfaces both for C and for Scheme could be translated into any
other reasonable language.  I expect that easy expansion to other
languages will be a primary design concern as well.  At the most
advanced stage, it may be possible to provide a "translation
framework" which performs string substitutions to produce output
files; alternately, adding a new target language might require the
writing of code to translate some intermediate representation into
appropriate output.

Also, as MCP seems to find its primary application in interfaces
between MOOs and either other MOOs or client applications, my focus
will be on constructing a system capable of dealing with standard MOO
data types: strings, integers, floating-point numbers, and
fixed-length vectors/arrays/lists.  Support for composite data types
in some fashion (i.e., C struct's) would also be a serious
consideration.  Support for complicated objects as seen in C++ or Java
would, I think, represent a great deal of additional work and raise a
wide variety of serious problems while adding relatively little
functionality useful to my perhaps-nonexistant "anticipated user".  I
think that even such a "minimal" interface would serve the anticipated
user base while representing a manageable task.  I think that
compliance with CORBA, particularly, would represent more work than I
am willing or able to put into such a project.

- --Nick Ingolia

Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface