[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Greetings and comments on MCP 2.1
Hi, welcome to the list.
I just want to point out that the following is all my opinion, except where I
say "we", and even some of that is just my opinion; it's not the word of some
Official Body On MCP Development. So take it in that spirit.
> (1) I like the introductory sections (though the use of "protocol" to
> describe application-specific suites is a bit confusing).
I agree. We say "the protocol" to mean MCP, and "a protocol" to mean a set of
messages and/or cords. It's messy. Let's change it.
> (2) I don't see the point of explicitly requiring an authentication key
The problem is, if you don't specify it in the spec, then you don't have a way
to require it in all messages. Unless we create another mechanism for that
sort of plug-in message arg. In which case whatever is plugged in isn't
really a message arg, it's something else again. And also it will take
another three years to do. Implementations that don't require auth keys
should feel free simply to do without them, though.
> 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)
Well, there _is_ a long and distinguished history of using colons to denote
keyword arguments (either at the beginning or the end of the keyword), so I'm
not sure they're all that cryptic.
As for object:verb, well, an earlier draft allowed colons in unquoted strings
as long as they didn't terminate the string, but that seemed to complicate
things unnecessarily. More importantly, this concern just seems overly
application- and server-specific to me. I think we just need to accept that
the existence of special characters means we're going to have to quote things
sometimes; it's not a major problem, as long as the rules are simple.
> , and I also
> think that there are a far greater variety of authentication schemes
> available other than merely authentication keys.
Yes. I guess I think auth keys should be _defined_ by the spec, but not
_required_. This way, applications that need them have them available, but
applications that don't can just skip it.
> For example, I can
> imagine the entire message being encrypted.
Not sure how you're going to encrypt the message and still have it conform to
> 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 )
I'm ambivalent about "regularizing" auth keys. Again, if used, they are used
across all messages; this seems less like a message argument and more like
part of the syntax. In the example you quote, by the way, the authentication
key is not being _used_; it is being _provided_. Subsequent uses all refer to
the key provided as an argument in this message.
> 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]
And, more generally, this can be dealt with at a lower level than we've
concerned ourselves with in this spec. I certainly don't want us to duplicate
all of TCP in this protocol just because someone else might not be using it.
Ordering is a problem that you'll have to deal with elsewhere.
> 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.
I'm tired of having this argument, and so I'll relinquish my previous position
(that we should have a single data tag for each message and its continuance;
although note that we still need a way to indicate that the message is
complete). Backward compatibility for deployed systems should be a concern,
though; but Jay, you're not using multi-line at all, are you?
Note that if you use data tags alone to indicate which message and argument a
particular #$#* line goes with, then you need to ensure uniqueness among all
contemporaneous argument tags; no additional complexity there, really, just
> 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.
Well, whitespace _within_ the body of a multiline argument is significant; I'm
not sure it's much different to ignore the whitespace that _begins_ the body.
However, I don't feel strongly about this either.
> (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
I would say instead that MCP itself will change much more slowly than the
> #$#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.
I'm pretty strongly opposed to this, if I understand it correctly. Our design
allows for negotiation strictly on a feature-by-feature basis; I don't think
that the server has any need to know what the name of the client I'm using is,
or that it should be making decisions based on that information alone. The
MCP implementations I've been involved with have among their goals:
* Make it easy to add functionality to the client/server, or remove it.
* Interoperate with other clients/servers that support some of the same
Requiring the server to know what a Supernova is or what features its version
1.6beta 2 supports seems like a very bad idea.
> (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.
Just to clear up a possible misunderstanding: Ours would also be
#$#audio-play, if there were a defined protocol named #$#audio or
#$#audio-play. The only messages that begin with #$#mcp are those that deal
with MCP itself--i.e., #$#mcp and the #$#mcp-negotiate protocol (and
#$#mcp-cord, although I still think that one's a mistake).
> 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 ).
(#$#* isn't a message name; it's part of the protocol's syntax. The goal, I
think, was to minimize overhead for multiline messages.)
> 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.
This sounds entirely in keeping with what we have; the only difference I see
is in whether one considers #$#* lines (and #$#END) to be messages in
themselves, or simply part of the mechanism for sending messages.
> (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.
I don't remember why we did this; in any case, I don't feel strongly about it,
so if no one else does, we might as well switch it.
> 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.
This is true, but only because VRML is (in your model) inherently
server-driven in practice as well as negotiation. On the other hand, imagine
a file-upload protocol. I could say "If the client does not upload files,
then it doesn't matter whether the server supports it or not. However, if the
client does do file upload, then it needs to determine whether the server
supports this or not before using it."
I think both of these statements are the wrong way to look at it. In our
spec, feature negotiation is neither server-driven nor client-driven; both
parties simply send their capabilities. The goal was to have the negotiation
over with as quickly as possible. If both sides send feature sets as soon as
they establish MCP contact, then each side knows that a supported feature is
present as soon as it receives one negotiate message from the other side. In
a server-driven process, the server must wait for a full round trip before
> 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.
Sounds good. It'll be interesting to see where the other participants in the
discussion so far disagree with my responses.