Re: Non-persistent Cookie proposal

On Sat, 12 Aug 1995, Koen Holtman wrote:
> James Gosling:
> >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.
> 
> Both my proposal and (I believe) the one by Dave Kristol intend to
> provide *some* minimal support for stateful dialogs as soon as
> possible, not to be the ultimate stateful dialog solution.

How the designers intend a protocol to be used, and how the users end up
using it, can be drastically different.  The protocol designers should be
aware of what people would want to use their protocol for.  If it turns out
that it's only safe when this new protocol is used in a particular manner 20%
of the time or less, and it ends up being used 90% of the time in that
manner, well, the protocol designer failed.  You can make recommendations...
you can call things "deprecated" or "discouraged"..  but when money is on the
table it's impossible to convince some people otherwise "for the sake of the
whole".  It's a good thing someone invented TCP before everyone discovered
the internet.  HTTP/WWW technology didn't quite have the same maturity 
before it was discovered, and now we're paying a cost for that.

So the question is - should we build in mechanisms to discourage
statefulness, while still allowing it, or should we wait until cache managers
start denying access to particular hosts?  I would like to work towards a
model where as little state as possible travels over the connection, and is
only sent when needed, hopefully less than 10% or even 3% for the most
stateful application.  Java is crucial for this, but a better model for
building client-side information bases is what's really on order (a la Paul
Burchard's ideas). Koen's and Dave's proposals have those critters flying
across the wire an *awful* lot. 

> >  When the web gets truly large, cache hit
> >rates have to be *very* high.
> 
> Imminent death of the net predicted.
> 
> I don't know if cache hut rates will *have* to be very high, or even
> if they will be.  I can imagine a large (but not necessarily fast)
> web, even without any caching.

Whether you can imagine or not doesn't really matter; the fact is that 
the number of people joining the net is *still* advancing faster than 
backbone capacity, and as those 14.4's wither away into memory with the 
arrival of 28.8 and ISDN and 10 mbps cable modems, bandwidth is going to 
become as precious as gasoline.  Furthermore applications like Internet 
Phone and CUSeeMe will put pressure on the backbone providers to start 
metering their IP traffic - when that happens it will *definitely* hit 
home that having local caches of information is a Very Good Thing.

> While I agree that a stateful dialog implemented with client-side Java
> scripts will generally consume less bandwidth, I don't think that Java
> browsers will be generally available, and, more importantly, generally
> used by more than, say, 90% of web users for some years to come.

Um, a lot of people doing a lot of relevant work are a lot more optimistic
about that.  There is a press release on home.netscape.com you should look
at. 

	Brian

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

Received on Saturday, 12 August 1995 15:31:05 UTC