RE: Comments about Network Information API

Hi, 

-----Original Message-----
From: Mounir Lamouri [mailto:mounir@lamouri.fr] 
Sent: Mittwoch, 21. März 2012 14:34
To: public-device-apis@w3.org
Subject: Re: Comments about Network Information API

On 03/20/2012 11:24 AM, Cheng, Diana, Vodafone Group wrote:
> 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.

I understand there are some issues with the current specification but I still believe that it's first of all better than the previous one (which was exposing a type attribute) and most raised problems should be handled by implementations. For example, if you switch from a data connection to another, the UA could fire a change event and set the bandwidth to an arbitrary value, then improve this value. 

>>How is an arbitrary value useful for a web application?

The same way, to prevent battery draining, the UA could prevent sending events if the bandwidth didn't change significantly enough.

>>Whether you raise the event or not, you need to test the bandwidth frequently enough, and then you determine if the change is significant enough or not. I'm not sure how you can avoid this frequent bandwidth test, and it will generate a lot of traffic and drain the battery. 

>>Also, don't you need the underlying native implementations to support this functionality as well? That is not the case currently, for example Android just exposes the type and subtype of connection.

Thanks and best regards,
Diana Cheng.

Received on Thursday, 22 March 2012 13:56:36 UTC