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

interface generator

Sure, an interface generator would be cool.  Since I have no intention
of actually _implementing_ an interface generator, I'll just freely
add desired features to the description.

>My initial conception of the tool would allow the generation of both
>client-side and server-side code in either MOO or C.

(I think of "client" and "server" as referring to the two entities in
an MCP _session_, while you seem to be using it here to mean the
sender and receiver of an MCP _message_.  But I get the idea.)

It would be nice to be able to plug in different languages, such as,
oh, I don't know, Java.  It should be fairly easy to write code for
each language that generates the sender and/or receiver side of a
given message, as needed.

Note that for certain languages, it would make sense to transform cord
definitions into object classes, and cord messages into methods on
those classes.

>Particularly, I
>expect that the issue of blocking RPC calls and return values will
>provide a subject for lively discussion.

There's no nothing of a "return value" in MCP at this point.  On
another project, we discussed the possibility of a canonical form for
"return value" messages.  For example, one side might send:

  #$#arithmetic-add op1: 2 op2: 2

and the other would respond with:

  #$#arithmetic-add-reply value: 4

I don't remember if we followed through on this.  Anyway, an interface
generator could automate such a convention.

>I would also like to remain
>as compatible as possible with any existing MOO MCP code, the state of
>which I am not certain.  

My impression is that there are at least four existing MOO-code
implementations of MCP infrastructure which are likely to be
compatible at some point with the MCP 2.1 spec.  Also at least three
Java client implementations, one Tcl client, and probably some other
ones I don't remember.  I don't know offhand of anyone implementing
MCP in C, although the subject has come up.

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.