- From: Ted Hardie <hardie@merlot.arc.nasa.gov>
- Date: Thu, 6 Jul 1995 09:15:37 -0700 (PDT)
- To: Brian Behlendorf <brian@organic.com>
- Cc: hopmann@holonet.net, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
The Session-ID: proposal and the idea of both sides of a connection being able to request that the connection remain open are not, I think, necessarily at odds. I agree that Session-IDs can be used to generate stateful information for use by servers, but there are situations when a maintained session may be a better idea for resource allocation reasons or because of the type of data the server will be putting out. Consider as an example the current "server-push" Netscape animations (these mimic the behavior of a server-initiated maintain, without negotiation--the server just doesn't close the connection). As I mentioned to Alex in email, there are times when the server knows what kind (and amount) of data will be put on the wire and the client does not. In the clicktrail example, I believe that many things could be accomplished by Session-ID:, but that some fairly important things could not. In a Session-ID: clicktrail you get information about what documents are selected as they are selected; with a maintained connection you could instrument a browser to provide information about what is done with the information while it is being viewed on the client end. Even knowing whether the browser was the active application during the "dead time" that appears in server logs would be a big win in our understanding of what the users are up to. Given the negotiation needed for client-initiated sessions, I don't really see disadvantage for letting the server negotiate something similar with the client. Regards, Ted Hardie NAIC
Received on Thursday, 6 July 1995 09:13:04 UTC