RE: Network Information API

From: Yoav Weiss [mailto:yoav@yoav.ws]
Sent: Thursday, December 06, 2012 9:27 AM
To: Brian Leroux
Cc: public-device-apis@w3.org
Subject: Re: Network Information API

I agree that you cannot conclude bandwidth from network type (I'm not sure I'd call that lying though) without considering reception, packet loss and RTT, and even then your result will probably be inaccurate.
The question is, do we want to create such an abstraction (and have each browser implement it differently) or expose the underlying properties to the Web developer.
IMO, if we do want to create such an abstraction, naming it `bandwidth` is confusing.

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