- From: Koen Holtman <koen@win.tue.nl>
- Date: Thu, 15 Aug 1996 19:59:37 +0200 (MET DST)
- To: Koen Holtman <koen@win.tue.nl>
- Cc: ses@tipper.oit.unc.edu, koen@win.tue.nl, mogul@pa.dec.com, jg@zorch.w3.org, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
I wrote earlier in a reply to Simon Spero: > >I don't see how you can ever get the numbers working for user profile >caching. After reading Simon's HTTP-NG proposal, I must add something here. It seems that HTTP-NG proposes a lot more than just user profile caching, and additional mechanisms in the proposal *will* make the numbers work for HTTP-NG in the case I analyzed in my earlier message. Summarizing what I read Simon's text, it seems that HTTP-NG is not proposing plain profile caching as a negotiation scheme, but a PEP-like negotiation scheme, in which the initial request is kept small by allowing the server to go back and ask for more profile data. In HTTP-NG, profile caching would only be an optional optimization on top of the PEP-like scheme. I thought that Simon's profiles would be 5K chunks of data containing all information about a particular area of negotiation. Instead they will usually only contain those capabilities and preferences the server actually asked for in the past. I also wrote: >It seems to me that only transparent content negotiation scales for >P_same values of 1 in 1 million or more (while also still protecting >privacy). I now think that HTTP-NG negotiation will also scale for these P_same values, and that it will also allow privacy to be protected. It is plain user profile caching, without any additional mechanisms, that won't scale. I think that the HTTP-NG form of profile caching could also be effective as an optimization on top of transparent negotiation (in the case where many requests are done on the same server). The optimizations I have now in the transparent negotiation draft don't concern themselves, like HTTP-NG does, with squeezing every last byte from the request message. They instead cut RTT delays by using proxy caches to respond to the request whenever possible. As for the main problem discussed in this thread, how to share data for negotiating around bugs the browser vendor does not care about: it seems that an internet draft to solve this problem would have to define a substantial amount of new stuff, beyond what is now in both HTTP-NG negotiation and transparent negotiation. Koen.
Received on Thursday, 15 August 1996 11:02:59 UTC