notes on an mcp 2.1 implementation in moo

[Erik Ostrom <eostrom@research.att.com>]

These are my preliminary notes on what should be changed from the
LabSpace MCP dispatcher to get to 2.1.  This is not likely to be of
interest to too many people, but I thought I would send it here
for those who care.

Something needs to keep track not only of which protocols each player
supports, but which version of the protocol is being used by the
player.  My plan is to make $player.client_protocols contain an alist
of {protocol object, version} pairs, rather than the current list of
protocol objects.  Currently, version negotiation is basically not
done.

I don't know what else has to be done with versions to make it
reasonable to support multiple versions of the same protocol.  It
seems to boil down to a question of how the work of protocol
management is divided between protocol objects and applications.
Probably I'll provide a way for applications to query whether a user
supports a specific _version range_ of a protocol.  And I'll keep the
current one-object-per-protocol-name scheme, rather than make multiple
objects to represent different versions of the same protocol.

I'd like to move all the MCP support currently on $player to an
ancestor of $player, named something like "generic MCP-capable
connection".  Just to keep it separate.

The mcp-negotiate-end message should be added.  I also plan to add a
way for :handles_client_protocol to be allowed to suspend until the
answer is known (i.e., until we get a relevant -can message, or an
-end message).  Assuming we keep mcp-negotiate 1.0, this should read
"until the answer is known or a given amount of time has elapsed".

I'd sort of like to change protocol:client_mcp_* to :send_mcp_*.  I
find the "client" there real unintuitive.  (In particular, I never
know which of :mcp_can and :client_mcp_can is the one that goes out,
and which is the one that comes in.)

Cord identifiers need to be unique.

It should probably be possible for the server to cope with a
client-initiated cord.

[Spec note: I believe the section on cord IDs should merely state that
IDs for cords generated by the endpoint that initiated the connection
should begin with "I"; that IDs for cords generated by the endpoint
that received the connection should begin with "R"; and that IDs must
be unique within a session.  No client/server talk, no algorithm.

What exactly are the rules for cord IDs, aside from the first
character?  Alphanumeric?  Identifier syntax?  Any value?]

Double-check the BNF.

Double-check auth key stuff.

Probably some support for dns- protocols would be useful.

I plan to change the API for cords, such that (a) applications get
direct access to cord objects, rather than going through $cord, and
(b) it's possible to use subclasses of the generic cord stub, so
that application-specific state can be stored on the cord.

Okay, that's all.  Just thought I'd share.