- From: Mercurial notifier <cvsmail@w3.org>
- Date: Fri, 23 Nov 2012 15:17:36 +0000
- To: public-dap-commits@w3.org
changeset: 283:17da00aa9160
user: Mounir Lamouri <mounir.lamouri@gmail.com>
date: Fri Nov 23 15:14:23 2012 +0000
files: network-api/Overview.html
description:
Some changes based on Frederick Hirsch suggestions.
diff -r a9958fccfa31 -r 17da00aa9160 network-api/Overview.html
--- a/network-api/Overview.html Fri Nov 23 14:24:17 2012 +0200
+++ b/network-api/Overview.html Fri Nov 23 15:14:23 2012 +0000
@@ -59,12 +59,11 @@
<section>
<h2>Use Cases</h2>
<p>
- 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.<br>
- 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.
+ 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 needed to
+ enable this, allowing it to become more common.
</p>
<p>
A few hypothetical examples would be:
@@ -85,28 +84,28 @@
<section>
<h2>Outstanding issues</h2>
<p>
- The specification currently request the <dfn>user agent</dfn> to show
- two properties: <code>bandwidth</code> and <code>metered</code>. Both
- are currently facing some disagreements.
+ The specification currently requests the <dfn>user agent</dfn> to
+ expose two properties: <code>bandwidth</code> and
+ <code>metered</code>. The working group currently does not have
+ consensus on these.
</p>
<p>
- <code>bandwidth</code> 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.
- <br>
+ One concern is that <code>bandwidth</code> 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.<br>
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
<dfn>user agent</dfn>. For example, having a set of values like
<code>very-slow</code>, <code>slow</code>, <code>fast</code> and
- <code>very-fast</code>.<br>
- Another solution would be to have only values like
- <code>very-slow</code>, <code>slow</code> and the empty string.
+ <code>very-fast</code>. Another solution would be to have only values
+ like <code>very-slow</code>, <code>slow</code> and the empty string."
</p>
<p>
- <code>metered</code> 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 <dfn>user agent</dfn>. That way, the
+ <code>metered</code> 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 <dfn>user agent</dfn>. That way, the
attribute could return a value based on a heuristic, on knowledge of
the current connection status or even by directly asking the user for
the information.<br>
@@ -338,7 +337,7 @@
}
gPreviousMetered = navigator.connection.metered;
- if (navigator.connection.metered) {
+ if (!navigator.connection.metered) {
gIntervalId = setInterval(poll, 1000);
} else {
clearInterval(gIntervalId);
@@ -361,7 +360,7 @@
<section class='appendix'>
<h2>Acknowledgments</h2>
<p>
- Special thanks to Robin Berjon for his help.
+ Thanks to Robin Berjon, Frederick Hirsch and Jonas Sicking for their help.
</p>
</section>
</body>
Received on Friday, 23 November 2012 15:17:41 UTC