W3C home > Mailing lists > Public > public-device-apis@w3.org > February 2014

Re: CfC: Shelve Network Information API, respond by 25 February 2014 (next Tuesday)

From: Marcos Caceres <w3c@marcosc.com>
Date: Wed, 19 Feb 2014 16:34:22 +0000
To: Mats Wichmann <m.wichmann@samsung.com>
Cc: Frederick.Hirsch@nokia.com, "public-device-apis@w3.org >> "public-device-apis@w3.org"" <public-device-apis@w3.org>
Message-ID: <6166587BF4634535AB5EB82E92BB547C@marcosc.com>

On Wednesday, February 19, 2014 at 4:12 PM, Mats Wichmann wrote:

> Disappointing based on the fact that it seems to be something that
> certain developers think they need, 

Not really. What they think they need and what they actually need are different things (see [1]). For instance, <picture> + client hints + resource priorities + resource hints cover the use cases much more effectively. As do better support for adaptive streaming protocols for audio and video. 
> and thus it's one more excuse for
> avoiding switching to "html5 apps", but a +1 on the proposal based on
> seeing no clear path to finding consensus on this one.

Again, the solutions above take a lot of the guess work out of bandwidth detection (and avoid other foot guns the Network Info API could have introduced into the platform). The things I listed above are much better solutions than those provided by native platforms, IHMO - but you are right that as long as we don't have these solutions, the web platform will continue to be uncompetitive here. The good thing is, we have general consensus that those things listed above are better than the NetInfo API.  
We will probably need to resurrect Network Info once the technologies I listed above are implemented in browsers (~2 years) - particularly for the large download use case, which seems to be the only valid use case for this API. 

[1] https://github.com/w3c-webmob/netinfo
Received on Wednesday, 19 February 2014 16:34:53 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:02 UTC