- From: Levine, David M. <DLEVINE@ssf4.jsc.nasa.gov>
- Date: Wed, 10 May 95 08:38:00 cdt
- To: HTTP Working Group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Thanks to everyone for the responses. As Dan Connolly and Barry Johnson noted, the "mxb" feature is a pretty much what I was looking for. Another question: how often is it actually used? I set up a small script to look for it from people accessing the page, but haven't found it yet. Also, Barry Johnson noted: >This is a nice idea, except for a couple of things: you are assuming the >browser is the weak link. If I am browsing through a relatively empty T1 >(say in my office at night) but connecting to a personal web server running >through a 28.8 or ISDN connection, the server is the weak (slow) link. If I >then point my browser through a wide-open T3 across town, I may as well get >the high bandwidth graphic. And Brian Behlendorf said: >Back to the proposal: the problem is that "bandwidth" is much more that just >how fast your connection is. For example, I'm hooked up to Sprint's and >MCI's backbone via three T1's to my desk, and I sometimes see object transfer >rates of 140k/second from nearby hosts, but there are times in the middle of >the day when the backbone is heavily loaded that I don't get better than >2k/sec even from hosts at large well-connected universities. So, specifying >my connection speed in an HTTP header doesn't seem to be the smartest thing >in the world. Additionally, just because I have a fat pipe doesn't mean I >necessarily want to see pages with 300K of inlined images and backgrounds. So I suppose I was unclear. I didn't want this field to be the rated speed of the line, but rather the actual speed at which the browser is receiving data. The problem, of course, is that is would be different for different sites. One possibility, as Mr. Behlendorf suggested, was to have a value set per top-level domain (although this was suggested for a "general quality value" rather than connection speed). This would work, of course, for cross-atlantic connections; but as we all know, there can be a wide disparity in server or connection speed even among local .edu or .com sites. An automatic session average per top-level domain might help somewhat... but there will always be sites that simply don't fit the averages. Additionally, Mr. Behlendorf said: >in the world. Additionally, just because I have a fat pipe doesn't mean I >necessarily want to see pages with 300K of inlined images and backgrounds. So, of course, just as low-bandwidth users need the ability to specify high-bandwidth pages, the reverse would also need to be true. Barry Johnson expressed concern over too many things needed to be set by a user on their browser. My thought on this was that if the user didn't want to be bothered, the XferRate would simply be automatically calculated as the session average. In a "preferences" area, if the user wanted, they could set it to one of three options: "high bandwidth", "low bandwidth", or "specific speed". The last option would allow the input of a specific number. The first two would simply be an arbitrarily high and low number. Finally, again, the "q", "mxb", and "mxs" values seem to be what I'm after. The reason, perhaps, that many browsers do not set them is that the values would be rather difficult to set, especially for inexperiences users. For instance, how would someone with very little technical knowledge decide how many bytes are of zero value, even if available immediately? Again, perhaps, there could be a simply button control for "high/low", and the browser would decide what values are needed. Personally, I like Brian Behlendorf's idea for a "cyberspace volume control" knob. This might be the simplest thing to do, and it could be directly on your viewing page instead of hidden away, and therefore changable from page to page very easily. Mr. Behlendorf also asks what current header such an attribute could be attached to. Why not tag it onto Accept? Again, thanks for everyone's comments. Also, SHOULD this be on www-talk? David Levine dlevine@ssf4.jsc.nasa.gov or lunar@sunsite.unc.edu
Received on Wednesday, 10 May 1995 07:36:44 UTC