Re: Network Information API

The info below is now available at:  
https://github.com/w3c-webmob/netinfo/

It contains the images in line, plus additional clarifications of how things work - particularly with relation to the audible app on iOS.  

It would be great if people could help add *real* examples from Android, Windows, BlackBerry (that means you, Josh! ;) ) etc.  

PRs welcome!  



On Saturday, December 7, 2013 at 6:29 AM, Marcos Caceres wrote:

>  
>  
> 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/ (http://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.
>  
>  
>  
> Attachments:  
> - photo.jpg
>  
> - photo.jpg
>  
> - photo.jpg
>  
> - photo.jpg
>  
> - photo.jpg
>

Received on Saturday, 7 December 2013 02:21:03 UTC