Re: Greetings and comments on MCP 2.1

[Michael Brundage <brundage@piaf.ipac.caltech.edu>]

On Thu, 7 Aug 1997, Andrew Wilson wrote:
[excellent points drawn from the example of HTTP]

As I said in my response to Erik's message, I don't mean to say that 
feature support should be determined by the name of the user agent.  
However, I do think it can be useful to provide that information to the 
server, in case it wants to make special use of it.

It is, however, interesting to contemplate your suggestion that
> In all likelyhood a proliferation of allegedly compliant browser/server
> implementations, will be closely followed by a rash of hacks and
> kludges, probably keyed from the user-agent value to counteract broken
> client/server behaviour.

I could sit around all day and criticize HTTP and HTML for their 
technical merits (or lack thereof), and I hope that this won't end up 
being true of the MCP we eventually adopt.  Is it true that we should 
anticipate a lot of client-specific hacks in the server-side handling of OOB 
stuff?  Will the average programmer deal with it on this level?  Or a 
higher one?

I like using audio as an example to illustrate my thoughts on this point, 
so let me try that now:

Clients will have different audio capabilities.  This is clear.  On the 
other hand, there are certain things which every audio feature should be 
able to do, independent of the client used.  For example, every client 
should be able to play a sound, although what audio-file formats they 
support is maybe open-ended.  Some may support the automatic generation 
of audio for environmental effects (such as dropping an item or closing a 
door).  Some will do stereo.  Some will do multicast audio.  Etc.

What level will the programmer deal with these?  Let's say I create a toy 
gong, which is associated with a certain sound file.  Playing the gong 
broadcasts the sound to everyone in the same area.  Some users won't have 
audio; for them, a string description will need to be sent.  Others will 
have audio, but may not have any idea what a gong is, or even that the 
sound came from it, so a string description will be useful to them too, 
in addition to the sound.  For the programmer who makes the gong, this 
will probably all be done with a simple:
  thegong.location:broadcast_sound(thegong.sound);

For the programmer who makes the room, there will probably be a MOO-wide 
specification of a sound, say a list of { description, sound-file}, so 
that $room:broadcast_sound() does something like
  { desc, sound } = args;
  for each in (this:users_here())
    try
      each:tell(desc);
      if($client_utils:has_audio(each))
        each:play_sound(sound);
      endif
    except e (ANY)
      "catch errors in users' :tell() and :play_sound()";
    endtry
  endfor

None of this assumes anything about the client in use at all.  It's done 
at a high level abstraction of "This is a sound, this is how you play it 
for the user."

But the core hacker (or authors of in-db client handlers) does have to 
worry about the low level details...  Perhaps they're a more reasonable 
lot, who won't resort to relying on the client name to determine feature 
sets.  In any case, as I've already observed, available features in our 
client come and go, so you pretty much *have* to ask the client what it 
can do...
 
> In addition, the dynamic of emerging technologies is essentially a
> marketing and statistics gathering exercise once the initial product is
> released.  In this case the elements of a standard protocol which
> support record keeping (user agents, client software version numbers)
> will receive much attention, futher blurring their relevence to the job
> of understanding client capabilities.

but I think you're right on this one, or at least it's been true in the 
past.  I'm surprised that there isn't more Java software out there that 
checks the runtime System properties and says, "I don't like the machine 
you're using, so I'm not gonna run."  Of course, System properties 
weren't available in the first version of Java, but now they are; are a 
lot of programmers using them?  I'm not, but that doesn't mean anything.

> I think a client-initiated negotiation sequence is best.  The question
> boils down to
> 
> 	"how does this client know that this server is able to understand
> 	MCP messages before the client has sent the first message?"
> 
> HTTP clients solve this by the 'http://' fragment of a URL.

MOO clients could solve it by connecting to different ports.  Dave and I 
have talked a lot about this, because of the following problem:

Suppose you have the same port listening to Web clients, fancy clients 
(with OOB handling), and plain clients (telnet).  On the one hand, you 
don't want the server to send any text to the Web clients, because it 
screws up the browser.  It doesn't especially matter whether welcome text 
is printed to the fancy clients; they can display it or ignore it - 
whatever.  The plain clients need something telling them what to do, or 
they may not even realize they're connected.

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.

The other solution is to just listen to different ports, and use the 
.server_options welcome message to customize the behavior through that 
port.  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.
This is the only solution we've been able to come up with; but the 
problem also works in the other direction:  Fancy clients shouldn't 
send messages to the server the server can't understand or handle.

It is perhaps interesting to note that Jupiter (before there were 
multiple port listeners and .server_options for each) handled this by 
just waiting for the *** Connected  message to determine the user was in, 
and similarly listened for the ** Disconnected message to close the 
connection.  Yuck.

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

I envision a system in which the login process is completely supplanted.  
The server finds out the user has GUI capabilities, and pops up a custom 
login prompt (perhaps a box with username/password fields like one often 
sees for logging in in other contexts, perhaps a registration process, ...).
In this case, OOB messages are sent *prior to logging in*, and so in fact 
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.)

> Someone has to go first, I think it just makes more sense if it's the
> active partner in the connection, the entity that initiated the
> connection, eg the user's client.

Yep.

> The server driven approach costs less bandwidth, but we're not talking
> about gigabytes here, so what does it matter if a more costly solution
> simplifies the implementation by allowing client/server vendors to use
> exactly the same code to generate/understand negotiation sequences.
[...]
> But if I had to choose, it'd be for sake of asthetics.  I prefer the
> non server-driven approach.

Well, you all are starting to convince me.  I've been using a 
server-driven approach for this portion (feature negotiation) of the 
process mainly because Jupiter did it (so I'm familiar with how it 
works), not because it's necessarily the best way. I definitely see the 
argument that clients will sometimes drive the process, and that's okay 
too -- as long as someone is "in charge" of each individual feature 
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).  Maybe I need to research topic this more (references 
welcome...), assuming there are systems that do this sort of thing already.

> You know, I hand't the faintest idea that Supernova was on the way.
> Where have I been all year!?!

In the UK? :-)

We didn't propose it until last July or so, and won the grant sometime 
later, I forget exactly when (Sept? Nov?).  I actually put together the 
web site then, but never got around to putting the finishing touches on 
things, and it kind of laid fallow for awhile.  So it's my fault for not 
being more vocal about it.

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! :-)

Cheers,

michael