Re: interface generator

[Michael Brundage <brundage@ipac.caltech.edu>]

On 2/10/98 3:48 PM,  Nick Ingolia  [ingolia@mit.edu] wrote:

>My initial conception of the tool would allow the generation of both
>client-side and server-side code in either MOO or C.  A C-side client
>would provide functions which packaged up their arguments and sent
>them for an RPC call over the MCP channel.  A C-side server would
>accept out-of-band input over an MCP connection and, when appropriate,
>extract the arguments and call a C function.  A MOO-side client would
>provide verbs which packaged up their arguments and sent them for an
>RPC call over the MCP channel.  A MOO-side server would accept the
>appropriate out-of-vand input from an MCP connection and extract the
>arguments to call a MOO verb.  

Depending on the languages involved, there is actually no need to
have the interface compiler.  For example, MOO allows you to compute
verb names and then call them (with no other knowledge of the
interface the object supports) and Java does a similar thing through
reflection.  We've taken this approach with Supernova, and will
include an RPC service in the core functionality.  Of course, MCP
itself is a kind of explicit RPC.  In practice, I've found our RPC
to be useful for rapid development/prototyping a new service; then
you can move it into a dedicated message space for efficiency if you
want (or not).

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.

On 2/10/98 6:50 PM,  Erik Ostrom  [eostrom@research.att.com] wrote:
>With that in mind, it might be useful to be able to plug in not only
>different languages, but different APIs, so that the same interface
>generator could be used to create code that would work on multiple
>systems.  I expect there will be some shakedown and consolidation of
>these implementations, but not that much.

Yes, and if anyone implements an RPC system that involves a
compiler for creating client/server stubs, I would *highly*
recommend they read about CORBA and make their system
satisfy all the requirements of IIOP.

We decided to take the easy way out here and skip the compiler
system -- CORBA includes a lot of functionality we don't need,
and Java and MOO allow flexibility that C does not --
but if we ever did do it this way we would use IDL to specify
the interfaces, and make ourselves IIOP compliant.  Of course,
this involves a lot of other issues (e.g., there is no standard IDL
language mapping for MOO, so do you propose one to the OMG?),
but I think it is the clear way to go if you want to provide high-quality
cross-language support.  And as a bonus, your MOO could
then work with existing ORBs and well, coolness would ensue.

Also, once you've gone this far, you might as well take the additional
steps to put in the Registry and Naming Service and all the other
ORB gizmos, and turn your MOO/client system into a truly
distributed one.  This is a big project I think, not something to
be done on a weekend.  If anyone has taken a look at it and wants
to do it, let me know what client functionality you require and I'll
try to make sure Supernova has it -- I think a distributed environment
would be awesome for MOO, but unfortunately it seems to be
just outside the scope of what we're able to do with Supernova. We'll
be distributed, but only in the sense of client-server interactions,
not in the wider sense of client-server-client-server-server-client-...


Cheers,

michael
brundage@ipac.caltech.edu
http://spider.ipac.caltech.edu/staff/brundage/