FW: Re: HTTP problem or Mosaic problem?

• Mail folder: WWW Talk Apr 94-present
• Next message: Ken Fox: "Re: Concerns about HTML+ complexity"
• Previous message: KFox: "NON-DELIVERY of: NON-DELIVERY of: Re: Concerns about HTML+ complexity"
• Reply: Paul Everitt: "Re: FW: Re: HTTP problem or Mosaic problem? "

Errors-To: listmaster@www0.cern.ch
Date: Thu, 16 Jun 1994 18:10:15 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <Chameleon.4.00.4.940616085702.rdenny@bob386.alisa.com>
Errors-To: listmaster@www0.cern.ch
Reply-To: rdenny@netcom.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Bob Denny <rdenny@netcom.com>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: FW: Re: HTTP problem or Mosaic problem? 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Mime-Version: 1.0
Mime-Version: 1.0
X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc.
X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc.

On Thu, 16 Jun 1994 10:25:04 +0200  Jon P. Knight wrote:
>On Wed, 15 Jun 1994, Alan (Miburi-san) Wexelblat wrote:

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