[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Greetings and comments on MCP 2.1
Hi all,
Thanks for including us (me and Dave Van Buren) in your MCP:TNG discussion
list. As you probably know, we've been working on a new MOO client we're
calling Supernova with the bulk of the features of Jupiter (GUI toolkit,
multicast audio/video, client-side process communications, latency
control) as well as new features such as extensibility and dynamic
updates (both client-side and server-side), applet support, and so on.
When we fleshed out our grant proposal a year ago, we realized that we
wanted to use something slightly different from MCP or Jupiter's
client/server message system, so we drafted up something we called MCP
2.0, and then mostly forgot about it until earlier this year, when I
began devoting my full attention to our project.
Anyway, there is a lot of overlap between ours and yours; you can read
our spec at http://supernova.ipac.caltech.edu/projects/np/mcp2_0.html
where it is a part of the Network Places exhibit I advertised on moo-cows
a few days ago (http://supernova.ipac.caltech.edu/projects/np/ ).
Dave K. and Erik have already talked with me some about your proposed MCP
2.1, and Dave suggested I send my thoughts to mcp-dev, so here they are:
(1) I like the introductory sections (though the use of "protocol" to
describe application-specific suites is a bit confusing).
(2) I don't see the point of explicitly requiring an authentication key
or of using colons (':') to delimit key/value pairs. Instead, I believe the
authentication key should be just another key/value pair, and that equals
signs ('=') should be used as delimiters. I understand that both of
these were historically used in MCP 1.0, but I think that equals symbols
improve the clarity of the message (while colons are just cryptic and
also mean every verbref someobj:someverb has to be quoted), and I also
think that there are a far greater variety of authentication schemes
available other than merely authentication keys. For example, I can
imagine the entire message being encrypted. Treating the auth key as
just another key/value pair further regularizes the grammar. (And, in
fact, you treat it this way in the example on version ranges:
#$#mcp authentication-key: 18972163558 min-version: 1.0 max-version: 2.1 )
Using your first MCP message example, I'm saying I'd rather have
#$#say authkey = 12345 what="Hi there!" from= Biff to=Betty
than
#$#say 12345 what:"Hi there!" from: Biff to: Betty
(3) I like your specification of multiline (tagged) data, and have
updated ours accordingly. However, it could be more concise [and also
could include support for network latency in case lines
get out of order - though I concede this is not crucial for MOO connections,
which are TCP and hence lines will be received in the order they were sent]
In particular, instead of giving tagged data dummy values, give them the
data tag itself, and then use that tag (by itself) in the additional
lines sent. Also, I'm of the opinion that whitespace should be
generally ignored, so I don't like the idea of specifying only one
whitespace between delimiter and value. Instead, I think whitespaces
separating message parts should be ignored, and to allow leading
whitespace in multiline messages, one could simply have each value be
prefixed by a nonwhitespace character,which is not treated as part of
the text. Example:
Instead of #$#spam 12345 from: Biff text*: "" _data-tag: 9b76
followed by #$#* 9b76 text: Blah blah etc.
as described in your proposal, I propose
#$#spam authkey=12345 from=Biff text*=9b76 <- Note data tag here
#$#* 9b76= *Blah blah etc. <- some non-whitespace leading
character (here *) indicates the start
of the line
(The use of the datatag as a key name implies that datatags have to be
formatted accordingly (i.e., may not contain whitespace or the key/value
delimiter)).
(3) I don't like the explicit versioning scheme. In fact, I think that
MCP itself will not change much beyond MCP 2.0 -- however, the feature
set ("protocols") which the client supports will vary widely both in type
and version, as will the logic behind the client/server negotiation
process. In practice, I expect that min-version will equal max-version
(if we ignore MCP 1.0, which I'm inclined to do). In any case, if the
server is accepting clients speaking a variety of MCP versions through a
single port, then the opening statement of the clients to the server
must all be mutually compatible anyway, or the server will have a very
difficult time deciphering them.
So, I'd instead send only a version number (with no specified numbering
scheme -- the server will know which versions it knows, and will ignore
the rest), and allow unspecified, optional additional information such as
the client name, the client version (distinct from the MCP version), the
authkey, and so on. E.g.,
#$#mcp version=2.1 client=Supernova client-version=1.6beta2
In particular, we anticipate many different client types (with differing
feature support) which might all support MCP 2.1; e.g.
#$#mcp version=2.1 client=Jupiter client-version=0.9beta
#$#mcp version=2.1 client=TWin client-version=3.0
might also be perfectly reasonable startup messages from the client to
the server, and all three clients (Supernova, Jupiter, TWin) might have
the same #$#mcp functionality, but diverge from there in their
feature support.
(4) If you read our proposal, you'll see we too do something like
protocols (which we call features or commands), except that we don't append
them to "mcp". That is, what would be #$#mcp-audio-play sound=gong in
your proposal would be #$#audio-play sound=gong in ours.
Taking this a bit further (and also commenting on a previous message by
John to this list), I think there should be only one reserved message
name, namely "mcp". All other names are client-specific and may overlap
or conflict at will -- but all MCP clients must implement mcp (or the
required subset of it) in exactly the same way.
Thus I would change the message name for cords from #$#cord to
#$#mcp-cord, and similarly I would change the message name for tagged
data from #$#* to #$#mcp-* (or perhaps #$#mcp-tag ).
That is, message names (or "protocols" or "features" or whatever one
calls them) form a sort of namespace, in which mcp is a reserved portion
of the namespace (like java is in the Java Class Libraries). This is not
terribly unlike RPC (RMI, ..., pick your favorite acronym), and in fact
may be implemented by mapping message names to objects and the part
following the hyphen to verbs (methods, functions, procedures, ...).
E.g., #$#audio-play sound="gong" can be mapped directly into
$audio:play("gong") and vice-versa.
(5) Client/server protocol negotiation. In your proposal this is a
server-driven process (that is, the server kicks it off; in fact, it
sends the first OOB message). I definitely don't like this; the reasons
are spelled out in our proposal, but we strongly feel that the
negotiation process must be client-driven. The client should send the
first OOB message, and the client should be the one who makes the final
decisions about what protocol is used.
When the mcp negotiation process is finished, the client and server enter
feature negotiation, and this process is server driven; after all, if
the server does not contain VRML, then it doesn't matter whether the
client supports it or not. However, if the server does do VRML, then
it needs to determine whether the client supports this or not before
using it.
Again, all this is described in our proposal, which is essentially
complete except for the client upgrade process (which is optional
anyway). (In our spec, we use #$#client in the same places you use
#$#mcp, but since we can treat them as equivalent names for the same thing,
that's no problem for us.)
Anyway, I guess that's more than enough for now. I hope that we can all
agree on a single, uniform base from which to build our individual client
protocols, and I very much welcome further discussion on all these ideas.
Cheers,
michael
brundage@ipac.caltech.edu