Re: Network Information API

On Monday, December 9, 2013 at 10:03 PM, Tobie Langel wrote:

> On Monday 9 December 2013 at 00:53, Marcos Caceres wrote:
> > On Sunday, December 8, 2013 at 11:43 PM, Mounir Lamouri wrote:
> > > On Mon, Dec 9, 2013, at 0:21, Marcos Caceres wrote:
> > > > From the data we collected, the main cases appear to be:
> > > >  
> > > > * warn the user that this could cost them money (bbc website, only works
> > > > on Safari in iOS)
> > > > * give the user control as to whether large uploads/downloads should
> > > > happen over cellular.  
> > > > * Prevent accident data transfer over cellular, which could use up of the
> > > > user's download quota and/or cost them money.
> > >  
> > >  
> > >  
> > > As I see it, UC does not mean "what people do" but "what people could do
> > > if they have that tool".
> >  
> >  
> >  
> > What you appear to be describing is a strawman [0] (a theoretical situation - rather than something people are actually using today in one form or another which we can see clear examples of in other platforms). The problem with strawmens is that they can be filled with red herrings - which is why they stink (see what I did there? ;) ). I think that explains, as you say below, why this has gone around in circles for so many months.
>  
> The reason this has gone in circles for so long is different. We've been collectively looking for use cases for the the Network Information API, instead of looking for true use cases (i.e. what matters to the user)
>  
> Users care about three things here: optimizing perf (e.g. through prefetching), battery life (e.g. through batching network requests) and cost (e.g. through avoiding aggressive prefetching when roaming).

I don’t think most end-users would really know about “optimizing perf" and how network communication affects battery life (or how that works - nor should they care). However, if we say that developers are the users, which they are of the API, then yes - I also care about those.   

Prefetching and batching are the role of the browser (mostly through HTML), so an imperative solution in the form of an API would not really help here - particularly for stuff on the critical path that needs to show up quickly.  

That leaves 3 - cost.   
> Given the complexity and rate of change in this landscape, the network info API, whether in its current stage or in its previous incarnation (which distinguished edge, 3G and wifi) is pretty much useless to solve any of these.  

Yet, for some reason, it’s prevalent and very much welcome on native platforms?  

All the examples we’ve now documented seem to show having the ability to detect switching from Wi-Fi to cellular as a very useful thing - specially as it relates to cost. I really do encourage you to take a look at the documented applications - there is good rationale and good intentions to all the apps that make use of similar APIs on native platforms.  
> It also won't hold the test of time.

Maybe. But we can’t really sit around trying to solve tomorrows problems - we should solve those tomorrow. We have clearly documented use cases and requirements for network information now.  
> Already today, solutions are being developed to do network load balancing (which transparently combines cellular + wifi networks),

Citation would really help here.  
> tethering usage is booming (which completely blurs the lines: you can be on wifi yet using up your mobile phone's data plan),

Citation for “booming" would really help here too.  
> roaming costs are changing quickly trough legislation (e.g in Europe[1]),

This will only be for European consumers, no? If I’m visiting Europe, or a European is visiting a non-EU member, won’t they still pay through the nose?
> LGE is now as fast as most home wifi networks, etc.

Sure, but home Wi-Fi speeds could increase further and likely at faster rates than mobile technology rollouts (e.g., Australia’s Broadband rollout [2] serves as a perfect example of how things can go bad). Also infrastructure rollouts are subject to political meddling: From [2], “The fibre to the premises (FTTP) rollout was planned to reach approximately 93 percent of premises in Australia by June 2021, but following a change of government, it is now expected to reach around 22 percent of the population. This will be represented by a mix of greenfields (new development) areas where it wouldn't be cost effective to lay new copper, as well as some brownfields (established neighbourhoods) areas where the existing copper is affected by ground water or other factors, or simply where the NBN fibre rollout has already advanced to a point where it wouldn't be cost effective to turn back to copper.”

Consider also the case in South Africa, From [3]: “South Africa started the development of a local telecommunications industry in 1958. Despite a rather successful state policy for some two decades, the old state policies can no longer keep up with new designs of digital equipment. Many proposals are currently being discussed within the government and the telecommunications industry itself for future development. One attempt to liberalize the communications industry was to end the monopoly of Telkom and open up the sector for market competition. In addition, since the change in technology is so rapid and radical, local firms find themselves increasingly obsolescent in technology because the import and manufacture of digital equipment are expensive and its continual updating is necessary."

Anyway, the point being that it’s somewhat technologically deterministic to assume that this stuff will get better globally at a consistent rate (or will improve at all in the long term). The above rollouts of infrastructure shows that there are large scale issues with rolling out and maintaining infrastructure. It’s not really realistic to assume the telecommunication networks will continue to improve at rapid rates.  
> User also have very different usage patterns depending on whether they're favoring cost effectiveness or performance, where they're based, etc. For example, if the new legislation passes in Europe, it might be completely reasonable to favor LTE over wifi when roaming in Europe, however, one might want to have different settings when traveling elsewhere.

Sure. But it depends on the telcos actually dropping things like download caps, etc. I’ve not heard anything about that.   
> All in all, applications making network-related assumptions on behalf of users seems like a bad idea. A much better alternative is to let the user make these decisions, probably through UA/OS level prefs (with possible whitelisting of certain preferred origins).

Yes, this is the same conclusion that I’ve reached by researching the various applications. However, I like having options at the per-application level and I like the way that some applications “do the right thing” on their own (e.g., ABC’s iview automatically stops downloads when the connection switches from Wi-Fi to cellular - that saved me the other night while I was watching a show, as I only had 400Mb left on my data plan).    
> The network info API wouldn't help with this, so dedicated, resource-aware APIs would need to be developed instead. For example, an API could be designed to allow for file upload in the background. The UA could then choose to upload the files when it see fit. This could allow the UA to optimize not only for network conditions, but also for battery and CPU usage (e.g. upload files when on wifi, plugged in and with low CPU activity). Etc.

Sure. This is a valuable use case, but it’s just one of the use cases - this is also something I’ve been thinking about that could be a useful addition to the Fetch API + service workers.   
> I argue that rather than focusing on the network info API, I there would be a lot more value to make sure network-related APIs are resource-aware or have resource-aware counterparts. In a sense, that's how performance, security and privacy concerns are generally addressed: not by creating dedicated performance, security and privacy APIs (though that is sometimes useful), but by making sure all APIs are designed with these concerns in mind.

Yes, but these things are already covered by things like <picture>, and the forthcoming lazyload and postpone attributes - to name a few things. What we need to understand is if there is any value at all in just knowing what the connection type is, and when the connection type switches from one to another.    

I don’t have a strong opinion about the utility of this API (I know at least from personal experience constantly attached to my iPhone both at home and abroad that I really appreciate the little user options that rely on network information).  I certainly see the above things, like <picture>, as __way__ more useful/value to the Web than anything a network API can provide.
> More concretely, a document that lists mobile-specific networking concerns would be very valuable, especially if it's coupled with battery consumption issues and maybe even geo-location ones (GPS is battery-intensive and location data also can be obtained through cell towers and or wifi). This document could also list common **user** use-cases (e.g. content prefetching for offline use, etc.), along with an analysis of which current network-related APIs are resource-aware and which ones aren't. For example, there is no API to do low-level priority Ajax requests (e.g. for aggressively pre-caching data).

I’ve filed a bug to see if we can get the UC&Reqs document to be the above:
https://github.com/w3c-webmob/netinfo/issues/48
  
>  
> Hope this helps.
>  
> --tobie
>  
> ---
> [1]: http://www.theverge.com/2013/5/30/4378972/neelie-kroes-ec-net-neutrality-roaming-europe

[2] http://en.wikipedia.org/wiki/National_Broadband_Network  
[3] http://en.wikipedia.org/wiki/Digital_divide_in_South_Africa#cite_note-anga4-7

Received on Wednesday, 1 January 2014 12:23:36 UTC