W3C home > Mailing lists > Public > public-device-apis@w3.org > January 2013

Re: State of the Network Information API specification

From: <Frederick.Hirsch@nokia.com>
Date: Sat, 26 Jan 2013 14:35:18 +0000
To: <bdelacretaz@apache.org>
CC: <Frederick.Hirsch@nokia.com>, <public-device-apis@w3.org>
Message-ID: <1CB2E0B458B211478C85E11A404A2B27018EDD94@008-AM1MPN1-033.mgdnok.nokia.com>
In scientific applications I believe one doesn't just provide a number - one includes a confidence interval or an indication of precision etc.  So this makes sense to provide a qualification of the bandwidth as well with the data item.

Sounds like this would work with what Mounir was suggesting of allowing implementations to improve without radical rework - in this case the metadata item could change as implementations improve. Not sure if it should be source or something else.

regards, Frederick

Frederick Hirsch

On Jan 25, 2013, at 11:08 AM, ext Bertrand Delacretaz wrote:

> Hi,
> On Thu, Jan 24, 2013 at 9:57 PM, Mounir Lamouri <mounir@lamouri.fr> wrote:
>> ...It is up to the user agent to decide how the bandwidth is computed. It
>> might indeed be hard to have a precise bandwidth for each domain the
>> client is accessing but this is actually not the intent of the
>> specification. The user agent should provide something that has enough
>> precision to be usable (not 1 Mb/s precision for example) but it doesn't
>> need to be very precise (like 1 kb/s precision)....
> I'm new here, only learned about this spec last week so bear with me
> if my suggestion makes no sense...
> Could the bandwidth attribute be structured to include some optional
> metadata to help clients decide how reliable it is? For example:
> 1MB/s ; source=networkType
> 400kB/s; source=measured
> This would allow for future evolution of bandwidth measurements
> (including adding more metadata), and clients can ignore everything
> after the first semicolon if they don't care.
> -Bertrand
Received on Saturday, 26 January 2013 14:36:18 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:57 UTC