W3C home > Mailing lists > Public > public-device-apis@w3.org > March 2012

RE: Comments about Network Information API

From: Jorge Peraza <Jorge.Peraza@microsoft.com>
Date: Tue, 20 Mar 2012 20:09:38 +0000
To: JOSE MANUEL CANTERA FONSECA <jmcf@tid.es>, "Cheng, Diana, Vodafone Group" <Diana.Cheng@vodafone.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <6AD626F2D81A224B8885199CA8EAC60F9FAC4477@TK5EX14MBXC135.redmond.corp.microsoft.com>
Thanks for bringing this up,  I share the same concerns about the avaliable bandwidth property as well.  What's more, since the Editor's draft[1] recommends returning an estimated value, I'm afraid developers could end up finding the data too unreliable to use because of how different vendors may end-up implementing this property.

[1] http://dvcs.w3.org/hg/dap/raw-file/84a2fb7b753b/network-api/index.html

Jorge Peraza
Windows Phone

From: JOSE MANUEL CANTERA FONSECA [mailto:jmcf@tid.es]
Sent: Tuesday, March 20, 2012 11:30 AM
To: Cheng, Diana, Vodafone Group; public-device-apis@w3.org
Subject: Re: Comments about Network Information API

De: "Cheng, Diana, Vodafone Group" <Diana.Cheng@vodafone.com<mailto:Diana.Cheng@vodafone.com>>
Fecha: Tue, 20 Mar 2012 11:24:21 +0100
Para: "public-device-apis@w3.org<mailto:public-device-apis@w3.org>" <public-device-apis@w3.org<mailto:public-device-apis@w3.org>>
Asunto: Comments about Network Information API

Hi Working Group,

I'm not able to attend the F2F this week in China but I wanted to provide some feedback which can hopefully be addressed during the discussions there.

I have a few concerns with regards to the new draft of the Network Information API [1]. I found the previous one [2] closer to the Native implementations, specifically Android. I understand the reasons for the new proposal [3] but I think other issues arise with it.

The new changes in the Connection Interface require a measure of the currently available bandwidth in terms of MB/s, which can vary very very quickly (for example  as ones moves from outdoors to indoors with a mobile device: e.g. dropping from HSPA+ to GPRS). Since it can change so quickly, the bandwidth should be tested frequently enough in order to trigger the 'change' event whenever a significant change occurs. But testing for bandwidth requires to do some sort of "download" trying to get the "full bandwidth" during the test and that might generate a lot of traffic. As a user who pays for data I'm not sure I would be happy knowing that the browser is downloading data in the background just to constantly test for bandwidth. This also has the potential for draining battery, which is already a problem with many devices like Smartphones.

>> + 1. I have the same concern.

Also, how would the bandwidth measure be implemented for Android or iOS for example? If the bandwidth is unknown or cannot be measured 'infinity' should be returned but this is, from where I see it, much less useful than having at least the Connection type. The same goes for the 'metered' attribute [4], there is no Native implementation either (for example none in Android).

[1] http://dvcs.w3.org/hg/dap/raw-file/84a2fb7b753b/network-api/index.html
[2] http://www.w3.org/TR/netinfo-api/
[3] http://lists.w3.org/Archives/Public/public-device-status/2011Dec/0021.html
[4] http://dvcs.w3.org/hg/dap/raw-file/84a2fb7b753b/network-api/index.html#widl-Connection-metered

Best regards,

Diana Cheng
Web & Social Media Expert
Internet Standards, Group R&D
Vodafone Group Services GmbH
Mobile: +491735374317
Email: diana.cheng@vodafone.com<mailto:diana.cheng@vodafone.com>


Vodafone Group Services GmbH, Mannesmannufer 2, D-40213 Düsseldorf Amtsgericht Düsseldorf, HRB 53554 Geschäftsführung: Dr. Joachim Peters, Rainer Wallek

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at

(image/gif attachment: image001.gif)

Received on Tuesday, 20 March 2012 20:10:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:35 UTC