W3C home > Mailing lists > Public > www-talk@w3.org > July to August 1995

Re: Non-persistent Cookie proposal

From: James Gosling <jag@scndprsn.eng.sun.com>
Date: Fri, 11 Aug 1995 18:54:16 +0800
Message-Id: <9508120154.AA02893@norquay.Eng.Sun.COM>
To: http-wg@cuckoo.hpl.hp.com, koen@win.tue.nl, www-talk@www10.w3.org, dmk@allegra.att.com
>   > Simpler mechanisms are possible, for example [3].  The `solution
>   > space' for stateful dialogs has a number of dimensions:
>   > 
>   >  - simplicity of implementation
>   >  - time of general availability when standardized
>   >  - downward compatibility
>   >  - simplicity of use
>   >  - reliability
>   >  - amount of privacy protection
>   >  - maximum complexity of stateful dialogs supported
>   >  - amount of cache control possible
>   >  - risks when used with non-conforming caches
>   >  - amount of confusion on www-talk generated

One of the most important axis for evaluation of *any* protocol is how
it scales.  All of the stateful dialog proposals that I've seen on this
list score very low on this.  When the web gets truly large, cache hit
rates have to be *very* high.  If you take this goal as "required" then
a number of things fall out:
  - If you want to collect demographics, proxies have to be involved.
    They have to somehow act as aggregators.
  - Customizing pages based on things which are not cache keys is *evil*
    This includes many of the things that people do with server-side
    includes.
  - The many hacks that people do to deliver different pages
    based on which browser is at the other end just can't continue.
  - behaviour and state needs to be pushed out.  Things like shopping baskets are
    easy to do as Java applets.  Since there's no shared state between the
    client and server, everything is cacheable.  The server gets one "put"
    when the customer pushes "buy".
Received on Friday, 11 August 1995 22:18:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:18 GMT