- From: Dmitry Beransky <dberansky@ucsd.edu>
- Date: Thu, 02 Mar 2000 10:23:37 -0800
- To: www-talk@w3.org
IMHO, this wouldn't be very useful. For example, my usual transfer rate to Qualcomm's servers is 200-400KB/s, but when I visit sites in Russia, I'm lucky to get 6-7KB/s. So what should my header say when I connect to your site? Let's say I come to your site with a 1.5Mbs value in the header. You start serving me high bandwidth content, then someone posts a link to your site on /. and before you know the slashdotters are oversaturating your site's bandwidth and you can't sustain the high transfer rates any longer. The best way to deal with this issue is to maintain a running average of the bandwidth for each session on your server and adjust the content in real time accordingly. Cheers Dmitry At 09:15 AM 3/2/00, Tam Freestone-Bayes wrote: >Many sites and their users can benefit from the provision of more than one >http interface to a site - for example, the increasingly widespread >bandwidth discrepancy between standard modem and broadband connections may >encourage developers to produce both high- and low-bandwidth versions of a >site. > >Many sites implement this but rely on the user to manually select which >site they "prefer". > >If the site developer knew what the user's average download times were >upon their arrival, then this could be used to automatically determine >what level of information to display to the user before the first URL is >actually served. > >I suggest that a client side header (for example "Avg Speed: 38552" >representing bits per second, say, could be useful. It is the >responsibility of the client to calculate and maintain this figure based >on their average or maximum download speeds over the duration of a >browsing session. > >The header should obviously remain optional in any client implementation, >but the benefit of supplying it is high.
Received on Thursday, 2 March 2000 13:19:02 UTC