MOO-cows Mailing List Archive

[Prev][Next][Index][Thread]

Stateless HTTP (was connect_player() bf)



On Sun, 4 Aug 1996, Richard Connamacher wrote:
> First to say that I think a connect_player() / bind_connection() builtin
> function would be a good idea and a nice step in making the database more
> independant of specific server nuances.  I do, though, have to disagree
> with both of the reasons posted.  First, HTTP is by definition supposed
> to be _stateless_, which means that logging someone into a MOO through a
> web connection is actually against the HTTP specifications.
[snip]
> See above note about HTTP statelessness.  A logged in connection to the
> MOO via a java applet that's _served_ over HTTP is perfectly fine, but
> doing the actual perminant logged in connection to the MOO over the HTTP
> isn't, and also isn't really practical.  (You'd have connections logging
> in, then out, then in, then out, constantly.  Remember, HTTP connections
> are very brief and many.)  MOO HTTP servers are great (Believe me, I
> know), but be sure that you do follow the HTTP specifications and
> guidelines, including keeping web connections stateless, nomatter how
> much you might be tempted not to.

Yeah, and HTML documents are supposed to be content-driven, instead of
format-driven.  Ho ho ho.  What about client authentication or form
responses?  Stateless HTTP connections are what aren't really practical,
no matter what the standard says.  Even Java munges this one (see, for
example, slide 10 from "Network-based Applications: Extending java.net.URL"
in the proceedings of the Java One conference).

Although it's clear that Web browsers were not designed to handle
long-term connections (like ordinary MOO connections), adding a little
persistant data to an HTTP connection is not a Bad Thing IMHO, and is
quite workable in practice.  Once there's A Better MOO Client which is as
widely available as web browsers are, we can leave browsers (with
all their limitations) in the dust, and go back to doing things
The Right Way (TM).

:-)

michael






References:

Home | Subject Index | Thread Index