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

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