Re: detecting connection speed

On 05/12/13 10:51, Yoav Weiss wrote:
> On Thu, Dec 5, 2013 at 11:17 AM, James Graham <james@hoppipolla.co.uk
> <mailto:james@hoppipolla.co.uk>> wrote:
>
>     On 04/12/13 23:04, Ilya Grigorik wrote:
>
>         Somewhat of a tangent...
>
>         There have been multiple requests in the past to expose the "bytes
>         transferred" as part of Nav/Resource Timing API. While this is not a
>         panacea, I do think it would be valuable and could address a lot
>         of use
>         cases we're discussing here...
>
>
>     What use cases? I haven't actually seen a list of use cases people
>     want solved anywhere in this thread yet. Without that it is
>     impossible to tell if any particular API would be valuable or not.
>
>
> I've previously raised it on the list [1]. The main use-case I see for
> that is enabling RUM solutions to detect compression issues along the
> path, with the side-effect of enabling authors to experiment with
> client-side effective-bandwidth detection strategies.

Apart from the first one, those aren't very concrete use cases. A 
concrete use case would be something like:

"Youtube.com wants to serve video over the internet. In order to stream 
with minimal interruptions in the face of variable network conditions, 
it would like to dynamically adapt the bitrate of the streamed video to 
match the currently available bandwidth"

Of course this is an already-solved use case, but it is good in the 
sense that it refers to a real problem that an actual site is having, 
not a problem that we think a hypothetical site might  be having, and 
sets out some clear parameters for deciding whether the solution is good 
enough (e.g. "solution must work for video", "solution must allow 
adaption in realtime", etc.)

Received on Thursday, 5 December 2013 11:04:28 UTC