Re: Network Information API

Hi All,

On 05 Dec 2013, at 13:17, Mounir Lamouri <mounir@lamouri.fr> wrote:

> On Thu, Dec 5, 2013, at 17:51, Puneet Mohan Sangal wrote:
>> Hi, I'd like to know what's the status of the Network Information API
>> (http://www.w3.org/TR/netinfo-api/)? Is this work in progress?
> 
> There is some work happening around Chrome Apps to implement this API or
> something similar to this API [1]. It is not clear yet what will be
> implemented exactly. The proposal has a connection type information but
> it is a common agreement that exposing such information is a footgun and
> should be avoided. As the last message shows, there is some work on
> bandwidth estimation and hopefully it will make the bandwidth property
> useful and remove the need to know the connection type.
> 
> [1]
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/R5yYtHEPiw4

Generally I share the concerns outlined by Peter at [1]. That said, I have a proposal (comes with a use case!) I'd like to test with folks here:

Perhaps we could abstract the essence of this API into "slow network" and "normal network" events that fire when there's a significant change in the network conditions, and not try to guess the exact bandwidth and/or the connection type as in the current or previous iterations of the API.

When the implementation notices that loading resources takes longer than on average [2] it would fire the "slow network" event. And when the network conditions resume back to normal, the "normal network" event would get fired. It would be up to the implementation to come up with reasonable heuristics based on bandwidth, latency, connection type, or any other hint that may be available to the implementation in the future.

Here's a use case that may be familiar to some of you: A user is standing on a subway station, she enters the train, the train enters a tunnel, the connection gets slower, and then, the connection drops completely. When the train finally comes out from the tunnel the connection is back again, first slow, then back to normal. The following events would get fired in this scenario:

"slow network" -> "offline" -> "online" -> "normal network"

(We can argue whether "online" and "offline" events are useful as currently spec'd and implemented, but let’s leave that discussion for another thread.)

When an app gets the "slow network" event it knows it is time to adapt to the changed environment. For example, pull in the FB/Twitter updates before the network connection gets too slow, or downgrade the streaming quality of a video that is being streamed and/or inform the user that the experience may be degraded soon, for example. And for “normal network” similarly, but back to normal.

Any thoughts?

-Anssi

[1] https://groups.google.com/a/chromium.org/d/msg/blink-dev/R5yYtHEPiw4/_5Hm0tp3iQEJ
[2] (Perhaps the device does some periodic synching in the background, so it knows this before the web content does any fetches.)

Received on Thursday, 5 December 2013 14:24:23 UTC