W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1995

Re: State Wars, part XI (was: Revised Charter)

From: Shel Kaphan <sjk@amazon.com>
Date: Fri, 3 Nov 1995 16:15:16 -0800
Message-Id: <199511040015.QAA15835@bert.amazon.com>
To: Brian Behlendorf <brian@organic.com>
Cc: Koen Holtman <koen@win.tue.nl>, "M. Hedlund" <hedlund@best.com>, montulli@mozilla.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Brian Behlendorf writes:
 > On Fri, 3 Nov 1995, Koen Holtman wrote:
 > > M. Hedlund:
 > > >[Lou Montulli:]
 > > >>In fact, [Dave's proposal] reduces the capibilities such that it is nearly
 > > >>unusable for large scale applications such as online shopping.
 > > >
 > > >I disagree (as a programmer for an online shopping site).
 > > I agree.
 > Besides, hopefully this "extremely large shopping site" will be sufficiently
 > funded and motivated to build a shopping cart Java applet

I've been meaning to interject a slight note of pessimism into this
discussion.  People building sites that require stateful interactions
will not be able to completely switch over to *any* new scheme for
transmitting state for a good long time.  The reason is that so long
as a large fraction of the browsing public uses browsers that are
incapable of dealing with whatever new scheme is used (Netscape
"cookies", state-info, or whatever), purveyors of interactive services
will find it in their own interest to support the minimum feature set
possessed by the maximum number of browsers.  This means that
URL-encodings are here to stay for a while.

The next step beyond URL-encodings is a way to pass a session ID
around without screwing with URLs, while leaving the server to manage
a database.  It will be fairly easy for server operators then to
support hybrid schemes: browsers that support it can use a session ID,
while those that don't can use URL encodings, while the server manages
the state-holding database in both cases. As long as a substantial
fraction of possible users and customers uses browsers with no support for
special state mechanisms, server operators will have to support server-
side databases.  As long as they have to do this, only the most
resource-rich server operators will be able to support *both*
server-side databases and whatever special state-handling mechanisms
are built into different clients.  This will tend to slow progress.

If Netscape goes its way and the rest of the world goes another way (or
multiple other ways), it seems pretty clear to me that people who run
servers requiring stateful interaction will just continue to do it the
bad old way until the dust settles in ... a couple years ...?

The same goes for expecting special Java applets to magically solve this,
since it'll only work for people who have Java-capable browsers.

--Shel Kaphan
Received on Friday, 3 November 1995 16:21:51 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:15 UTC