RE: Network Information API

From: Niklas Widell [mailto:niklas.widell@ericsson.com]
Sent: Friday, December 07, 2012 2:12 AM
To: SULLIVAN, BRYAN L; Yoav Weiss; Brian Leroux
Cc: public-device-apis@w3.org
Subject: Re: Network Information API

There are measurable gains to be made given radio status info, but wouldn't this preferably be done in the browser rather than application? After all, it is the aggregation of all traffic from all web applications that must be well behaved for this scheme to work, and the browser is the aggregation point.

Note, I'm not arguing that radio adaption is a bad thing, just that it is a complex implementation detail that requires wide adoption by all web pages to be useful.


I don't assume that the browser has to be the aggregation point, since "aggregation" means that the browser would be making decisions on behalf of apps (re request timing at least), and that is a complex undertaking that I doubt browser vendors would want to be responsible for. I would rather leave this at the app layer with support from libraries, that allow developers to take advantage of rapidly evolving techniques implemented in javascript.

I also don't think that to be useful, this requires "wide adoption by all web pages". As I mention below, we have seen major improvements on an app-by-app basis through such techniques. These improvements have been very useful for users of those apps. Wider adoption will follow once developers see the advantage of context-aware network usage, and have easy ways to leverage it (e.g. freely available javascript libraries that use the new APIs to manage app-specific network request queues).

Regards
Niklas

On 2012-12-06 19:47, "SULLIVAN, BRYAN L" <bs3131@att.com<mailto:bs3131@att.com>> wrote:

Another, unrelated property that can be of great help to Web developers is the `radioState` property. What I mean by that is exposing the state of the radio (full power, low power or standby as defined http://developer.android.com/training/efficient-downloads/efficient-network-access.html) to Web developers, giving them the opportunity to pull extra data from the servers only if the radio is already in full-power, thus saving battery life.



Exposing the radio state would be very valuable, certainly provide much more actionable information than navigator.online or connection.bandwidth. Basing network request decisions based upon radio state could go a long way toward improving resource efficiency, at least for requests that can be delayed until an optimal time. We've proven this by achieving major reductions in device power usage for some of our lead app developers, through their use of our free ARO (at&t Application Resource Optimizer<http://developer.att.com/developer/legalAgreementPage.jsp?passedItemId=9700312>) tool.

Thanks,
Bryan Sullivan