Re: [network-info] Added use cases and mentioning outstanding issues

Thanks Mounir, this is a good improvement.

In example 3, shouldn't the polling not happen if metered, so isn't a not needed in the test in the following


  if (navigator.connection.metered) {
          gIntervalId = setInterval(poll, 1000);
        } else {
          clearInterval(gIntervalId);
        }

e.g.

  if (!navigator.connection.metered) {


also, some minor editorial nits

In 1.1 suggest changing

"
The main use cases trying to be solved by the Network Information API are use cases of applications trying to be gentle with the user's bandwidth when they know it is rare or expensive.
Even if they are not much applications trying to behave like that currently, this specification tries to build the required tools to allow this and hopefully making it more common."

to

"The main use case of the Network Information API is to allow applications to be gentle with the user's bandwidth when they know it is rare or expensive. Even if there are not many applications that do this currently, this specification offers the the tools need to enable this,  allowing it to become more common."

In 1.2 suggest changing

"The specification currently request the user agent to show two properties: bandwidth and metered. Both are currently facing some disagreements.

bandwidth is told to be hard to implement, can be quite power-consuming to keep it up-to-date and its value might be unrelated to the actual connection quality but could be affected by the server.
A solution to fix this would be to return non absolute values that couldn't be easily abused and would be more simple to produce for the user agent. For example, having a set of values like very-slow, slow, fast and very-fast.
Another solution would be to have only values like very-slow, slow and the empty string."

to

"The specification currently requests the user agent to show two properties: bandwidth and metered. The work group currently does not have consensus on these.

One concern is that  bandwidth may be hard to implement, can be quite power-consuming to keep up-to-date and its value might be unrelated to the actual connection quality that could be affected by the server.  A solution to fix this would be to return non absolute values that couldn't be easily abused and would be more simple to produce for the user agent. For example, having a set of values like very-slow, slow, fast and very-fast. Another solution would be to have only values like very-slow, slow and the empty string."

Change

"metered is also told to be hard to implement because there is currently no standard way for the OS to know if the current connection is metered but the idea of the specification is to leave the implementation details to the user agent. "
to

"metered may also be hard to implement as there is currently no standard way for the OS to know if the current connection is metered.  The approach of the specification is to leave the implementation details to the user agent. "

regards, Frederick

Frederick Hirsch
Nokia



On Nov 8, 2012, at 9:28 AM, ext Mounir Lamouri wrote:

Hi,

As discussed at TPAC [1], I've updated the ED of the Network Information
API to include a few use cases and the outstanding issues.

The updated draft can be found here:
http://dvcs.w3.org/hg/dap/raw-file/tip/network-api/Overview.html

Any feedback is welcome :)

[1] http://www.w3.org/2009/dap/track/actions/590

--
Mounir