Re: cookie draft available

>  > The implementation limits of 300 cookies and 20 per host seem a bit
>  > high (think of our friends writing the browser on the PDA), what
>  > went into that number?  (Depending on how you viewed sessions, for example,
>  > you could say 20 per host and 20 total--each session ending when you
>  > went to a new host.  That would be really limiting, obviously, but why
>  > 300?)
>Good point.  The numbers come from the original Netscape proposal.  Lou
>Montulli felt that application writers needed some certainty about what
>a client could save.  I don't have a good defense for 300 specifically.

I think that 300 is high if the cookies are to be used for state maintenance.
But if sitres want to use them for demographic data traking they will want many 
more. It is enough of a pain in the ass to have to log into the ney york times 
every day as it is.

If on the other hand we introduce client generated unlinkable session IDs
much of the demographic data excahnge stuff can be done with them instead and
cookies can be confined to operations that actually need state. This would mean 
that a person with a PDA could probably function at shopping malls etc with a 
very small number of cookies (20).

There is another benefit. Flushing the cookie cache need not disrupt the session 
information. Imagine the poor looser with a PDA is having hassle with an 
interaction. A very natural need would be to want to "reset" the connection and 
start from scratch. 

I'm minded of the Apple Mac problem here. I loath using Macs because they tend 
to be very opinionated about saving me from myself. This is all very well if the 
system is bug free. But when you hit a bug on a Mac you are likely to end up 
having to reboot because the system is waiting for an event that is never going 
to happen. I've often wanted a button to bypass some stupid warning box 
demanding that an application really quit rather than try to save files on a 
disk I took out of the machine for very good reasons. I think we need to provide 
the user with a way to avoid having to flush usefull information when trying to 
reset the system after loosing with some CGI monkey's broken perl scripts.


	Phill

Received on Thursday, 18 April 1996 17:27:24 UTC