Re: Web for MOO?

• Date: Thu, 2 Nov 1995 01:58:29 PST
• From:
  Andrew Wilson <andrew@tees.elsevier.co.uk>
• Content-Length: 3043
• Content-Type: text

Jay:
> > Firstly, the #$#mcp ... only happens if you've already determined that
> > your client is able to handle mcp using client options.  MOO remembers
> > your client's state and responds to you the next time you connect
> > assuming that things haven't changed.
> 
> Well, right now on JHM, this is hardwired.  Erik has been arguing hard
> for it to work the way you described though.  
> 
> There isn't a handshake defined in the existing MCP documentation;
> clients and servers know they can talk by private convention (eg, "MCP
> Enabled" in your client's world file and a @client-option on the
> server.)  In my draft 2.0 spec (sitting on my desk, don't give me any
> crap about this right now) this remains as an option, as well as
> something like what JHM does.  A more interesting option is to have a
> non-intrusive handshake starter, like a line consisting solely of 37
> space characters.

Barf. ;)  Still we're not alone in this dialemma.  There are really 2
well used HTTP protocols out there 1.0 which everyone's meant to use
and 0.9 which the first browsers used.  Web browsers talk to servers by
typically issuing a command like:

	GET /some/URL [protocol]

eg:

	GET /some/URL HTTP/1.0

or	GET /some/URL			for 0.9

There's this godawful kludge server-side which makes the server behave
differently depending on which of the two protocols it's asked to
speak.

What webservers *can* do that's funky is a thing called content
negotiation, it basically lets browsers have different preferences for
graphical and other formats and the server can then sensibly decide
which of any optional data types to send back.

Extending this idea, it'd be kuhl to have protocol negotiation, perhaps
enabled in the same way as webservers do contant negotiation by looking
for Accept: headers in the stuff the browsers send them.  Translating
into MCP speak we might see:

Client sends ...		     Server thinks ...

#$#accept protocol: line/mcp	     d00d wants to talk linemode MCP
#$#accept protocol: character/veil   d00d wants to talk character based VEIL

I don't know if there's a protocol negotiation model out there other
than what inetd does when it hears some unknown client talking on the
telnet port.  The very fact that it's yapping at telnet means that it
wants to speak line/raw-telnet or something.  Like I said, I dunno...

> > If you grep through JHCore you'll find a #$#client-options (or some
> > similar foo) which is sitting there waiting for the client to be first
> > to say what sorts of transactions it'd like to handle.
> 
> Right; the problem with #$#client-options is that it mixes up a
> particular client's ability to understand a protocol with a user's
> desire to USE that ability.  As my draft stands, negotiation only
> addresses capability, leaving the other part up for further
> experimentation.

Colder than the norm.


> > I understand that tk/tcl will be 'out' for PC/MAc platforms shortly,
> 
> Out in beta.  http://www.smli.com/research/tcl

Yeah, went there last week and they said 'RSN'.

Ay.

• Prev: Re: Web for MOO?
• Index: MOO-cows
• Thread: MOO-cows