[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Greetings and comments on MCP 2.1
> > 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
> 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
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
> > 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
> 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
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
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!