- From: Mounir Lamouri <mounir@lamouri.fr>
- Date: Fri, 23 Nov 2012 15:19:38 +0000
- To: public-device-apis@w3.org
On 14/11/12 14:53, Frederick.Hirsch@nokia.com wrote: > 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. " Thank you for those comments :) All changes applied: http://dvcs.w3.org/hg/dap/rev/17da00aa9160 Cheers, -- Mounir
Received on Friday, 23 November 2012 15:20:12 UTC