[Prev][Index][Thread]

# Re: Web for MOO?

- Date: Thu, 2 Nov 1995 01:58:29 PST
- From:
- 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

Home | Subject Index | Thread Index