- From: James Graham <james@hoppipolla.co.uk>
- Date: Wed, 04 Dec 2013 16:38:19 +0000
- To: public-web-perf@w3.org
On 04/12/13 16:29, Mark Watson wrote: > > > > On Wed, Dec 4, 2013 at 2:51 AM, James Graham <james@hoppipolla.co.uk > <mailto:james@hoppipolla.co.uk>> wrote: > > On 04/12/13 05:05, Puneet Mohan Sangal wrote: > > James, I understand it's a difficult problem to solve, however > it will > be a very useful dimension when conducting analysis on > performance data. > May be we should start with what the possible solutions could > be, and > then consider the pros & cons? > > > You should always start with use cases, because they form the basis > for determining what the pros and cons of possible solutions are. If > possible you should also back up use cases with evidence that they > are real problems e.g. people using workarounds to try and solve the > use case in the absence of a built in solution. In this case that > might be e.g. authors timing resource downloads to try to estimate > connection speed. > > > Timing resource downloads is a more direct measure of the only (or at > least main) property of interest - the achievable performance on the > current network connection, from a particular server and at the current > time. Adaptive streaming applications, for example, make extensive use > of resource download timing - directly or indirectly - to determine the > appropriate video rate to request. Right, adaptive streaming is a good example of where this kind of thing is useful (and afaik, already solved). In that case it works because the resource you are downloading is time-based so you can dynamically adjust your requested bitrate according to small-timescale data on network conditions. Since most other resources aren't like audio/video in this respect, the same approach wouldn't work. Hence the importance of defining use cases upfront rather than talking about solutions. (To be clear, I remain skeptical on general grounds that, even in the presence of use cases, there will be solutions that do more good than harm, but it is hard to be sure).
Received on Wednesday, 4 December 2013 16:38:47 UTC