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

On Fri, 3 Nov 1995, Shel Kaphan wrote:
> 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.

<sermon>
With a graceful framework for dealing with clients of varying 
capabilities, new capabilities can be introduced at any time without 
causing problems for clients of lesser capabilities.  That graceful 
framework is content negotiation.  Until that's taken seriously, Doing 
Cool New Things just gets more and more painful, and we get stuck in a 
morass of chicken-and-egg-isms.
</sermon>

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

The goal here is not necessarily to reduce the workload of the server
operators or server software authors - anecdotally and historically that's
been a very abundant resource.  Particularly since once this type of multiple
support is coded it doesn't have to be redone each time. The goal *should* be
to provide the most graceful, flexible, lowest-bandwidth, secure, and
privacy-protecting protocols and systems.  

I'm a pragmatist, too - if we were to implement a shopping cart, I would 
support what I had to to make it usable to the largest number of users, 
which would probably mean URL encoding as a base case.  My comment about 
Java apps was to try and give perspective to exactly what we want to be 
able to do with state maintenance.  Sending back and forth the list of the
100 CD's in my shopping cart with each access seemes excessive - even if 
it were just a bitmap of that info.

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

Again, think: graceful framework.  Graceful framework.  

	Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com  brian@hyperreal.com  http://www.[hyperreal,organic].com/

Received on Friday, 3 November 1995 17:47:25 UTC