- From: James Gosling <jag@scndprsn.eng.sun.com>
- Date: Fri, 11 Aug 1995 18:54:16 +0800
- 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 UTC