Re: Greetings and comments on MCP 2.1

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

> > HTTP clients solve this by the 'http://' fragment of a URL.
> 
> MOO clients could solve it by connecting to different ports.

_Excellent_ solution.  I'm satisfied with whatever gets decided about who goes 
first, in that case.  (In fact, a server that knows it's always going to be 
getting MCP-enabled clients can send its message without waiting for a message 
from the client; assuming we do switch to client-initiated negotiation, can we 
spec that clients should be able to deal with an _incoming_ #$#mcp message 
before they send an _outgoing_ in some cases?  Once again, I'm thinking about 
latency.)

> One solution is to set a timer on the incoming connection.  If it doesn't 
> say something before the timer expires, the server sends the welcome 
> text.  But how long is a suitable time, that is long enough not to 
> interfere with Web browsers and fancy clients and to correctly account 
> for network delays, but short enough to be friendly to the users of plain 
> clients?  We think there is no such time.

I've got a related problem for you.  Suppose I'm writing my MCP-enabled 
client.  Suppose, further, that there are some servers that don't want you to 
put up a conventional "MUD" window at all--they want to start with a dialog 
box, or have a special protocol for creating chat windows, or they're just 
tic-tac-toe servers so why would you have a chat window?  Suppose, finally, 
that I also want to be able to connect to servers that mix MCP messages (such 
as #$#edit) with ordinary MUD interaction, as well as plain old dumb-as-dirt 
TinyMUD servers.

So the question is, when should the client put up the traditional MUD window?  
If it starts with the MUD window as soon as it connects, that's going to be 
one useless and confusing window for the tic-tac-toe server.  If it waits for 
an MCP message to tell it to put one up, then it's going to be puzzling in the 
mixed-MCP case, and of course it's never going to happen on TinyMUD.

Our solution was this:  The first time you get a NON-mcp message from the 
server, you put up the MUD window.  So if there's a welcome message, you 
display it.  If there's interaction, likewise.  But if your server speaks 
entirely by way of MCP, then you never need to look like a MUD client.  (In 
this case, you may or may not want to have an MCP message that means "do an 
ordinary MUD window, but we'll use MCP to communicate in it".)

As a side effect, even on the all-MCP server, you also get the mud window 
popped up if you get a traceback.  For the MOO server implementation, this 
turns out to be kind of handy at the prototype stage--it's sort of an 
automatic debugger window.

Oops!  Was I speaking out loud?  Sorry, go on with your conversation.

>  In fact, this is entirely the reason I bugged Pavel so much to 
> make .server_options vary per listener, and not be a global MOO setting.

It's embarrassing that I don't know the answer to this, but:  Did Pavel fix 
that?

> > I detest the '#$#mcp foo: bar' message that shows up on connection to
> > some muds, though this might also be moderated by user account options
> > set in the server.
> 
> It's not just aesthetic; some clients will become fatally confused by 
> spurious OOB messages.

That sounds like seriously buggy client behavior.  Likewise, one can imagine a 
server that would become similarly confused.  But, you know, you take your 
risks; in either case, the only solution available seems to be "fix that 
client/server".

> user account options will not yet be accessible.  (Though client options 
> are available on the client side, and this is the place to store some 
> things such as "Connect as fancy client/connect as plain telnet" anyway.)

As much as possible, I would like users not to have to set this themselves.  
This has no bearing on anything, it's just it seems to keep coming up.

> negotiation.  But when both server and client toss all their options out 
> in the open, I don't see how to find a path to an agreement between the 
> two (see my last post on dynamic upgrades in response to feature 
> proposals).

Well, our spec just covers the question "what CAN you do?"  This is pretty 
easily resolved; you just take the intersection of what both parties can do, 
and use the highest version available where there's a range.

It doesn't speak to the question "what would you PREFER to do?"  Again, this 
is something that we've had no opportunity to get experience with; the 
question "whose audio protocol would you like to speak" hasn't come up in the 
absence of even a single audio protocol to decide between.

I guess my suspicion is that, in most situations, this question gets answered 
implicitly.  For example, having established that both client and server are 
capable of receiving/sending both RealAudio and StreamWorks audio, the 
question is resolved by the fact that the server sends RealAudio messages and 
not StreamWorks messages.  For any interaction that is initiated by one side 
or the other, the initiator gets to decide what protocol is used.  And, again 
for the most part, I think as long as both parties speak both protocols, this 
is fine.

There are certainly some subtler cases to be worked out.  But I don't think 
we're in a position to address them yet; I think they need to be worked out 
_as cases_ before we should define a general behavior.

> It's too bad Jupiter never made it into the public arena.  It would have 
> been a nice tool for everyone to use.  We're definitely hoping to release 
> our client, but I know some of you have fancy clients that will be 
> available much sooner.  How MOOing will change then! :-)

Well, I think the greatest lesson to be learned from Jupiter is "Don't count your chickens before they hatch"; I'd like to think that all of our clients will show up in public space, but the only one I'd really count on is Networker's.  And it's already out!

--Erik