[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


#$#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 

(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.