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
Nokia



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