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

Re: Network Information API

From: Marcos Caceres <w3c@marcosc.com>
Date: Fri, 6 Dec 2013 20:29:02 +0000
Message-ID: <CAAwChxMe4DwcGuXDMWtA0ptQ6Lp9ZVg0g2fnzvmQZhUhbwShVg@mail.gmail.com>
To: Josh Soref <jsoref@blackberry.com>
Cc: "Kostiainen, Anssi" <anssi.kostiainen@intel.com>, "<public-device-apis@w3.org>" <public-device-apis@w3.org>
On Saturday, December 7, 2013, Josh Soref wrote:

> Fwiw, I¹m considering a network information api which is based on network
> interfaces.
> interface NetworkAdapter {
>   string uuid;
>   bool connected;
>   string[] localaddresses;
>   string[] gateways;
>   /* possibly exposing dns server information */
> }
> With a notice going out for each up/down of each interface.
> When I take my phone and it switches from only having cellular to having
> cellular + wifi, I¹d get a notification for the new adapter, that
> notification is a hint that routing may have changed and performance
> characteristics may be different.

And then what will you do with this information (change some HTML? Show
something to the user?)? Like you say, the characteristic *may* be
different, so how do you stop yourself making a bad decision?

> For BlackBerry devices, there is a third network which can easily go
> up/down which is the Work network (it¹s roughly a VPN), and then there¹s
> also a normal VPN connection available ‹ each would notify (but only if
> they¹re available to the given application ‹ the Work network may or may
> not be exposed to non Work applications at the user/admin¹s discretion).
> I haven¹t started prototyping this, but I believe that in theory this
> covers all the actual use cases I can imagine.

Which are?

> When routing changes, it¹s quite likely that performance characteristics
> will change.

And so you do X to your application to achieve Y. What's X and Y? And are
there actual *real examples* of people relying on that?

Here are concrete ones I have seen: on bbc.co.uk/news/ when you try watch a
video on cellular it warns you that it might cost you money if you proceed.
I don't know how they did that, but we can ask them. Image attached.

The Audible app on iOS won't let you download books over XXmb unless you
are connected to wifi. However, it provides an override in its setting.
Images attached.

IOS can tell a user that an update is available, but does not allow d/l the
unless they are on WIFI. The AppStore also does not allow users to download
apps over 100Mbs unless they are on WIFI. Image attached.

IOSs AppStore stops you d/l apps over 100Mb over cellular. It will queue
them for d/l for when you next connect to WIFI. If you go from WIFI to
cellular in the middle of a d/l, it stops the d/l. Image attached.

In a separate incident, I did once explicitly  allow Audible to d/l a 100mb
Audio book because I really wanted to continue listening to a book that had
only partially d/lded. Image of override option attached.

Hope that's enough to start building an actual use cases doc from. You can
also reach out to the WebMobIG for help.

> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.

(image/jpeg attachment: photo.jpg)

(image/jpeg attachment: 02-photo.jpg)

(image/jpeg attachment: 03-photo.jpg)

(image/jpeg attachment: 04-photo.jpg)

(image/jpeg attachment: 05-photo.jpg)

Received on Friday, 6 December 2013 20:29:31 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:01 UTC