> [...] IMHO
>HTTP has been successful partly because it is easy to implement a basic
>server...
Well... I might disagree with that. :-) :-)
>and it doesn't rapidly overload the machine. If people feel they
>need a stateful protocol, I think they should come up with something new
>rather than subvert the statelessness of HTTP.
I WHOLEHEARTEDLY AGREE!! I have quietly observed the chatter about navigability,
etc. and it is clear that there is a need for something that can provide more
structure. If you want to learn about the impact of keeping state at the
connection level, look at any busy FTP installation. Now imagine the client
reading and maybe printing documents while staying connected to the server all
the while. All those forked subprocesses laying idle a large fraction of the
time. And the what happens if the link is broken?
On the other hand, it is possible TODAY to implement a "stateful" application,
using CGI. It would be up to the back-end and the client to work together to
identify the "session", perhaps with URL-encoded "handles". This seems FAR
better to me than trying to keep state at the HTTP level or the connection
level. You could start a session, go to bed, and pick it back up the next
morning.
-- Bob