Re: Network Information API

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).

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. It also won't hold the test of time.

Already today, solutions are being developed to do network load balancing (which transparently combines cellular + wifi networks), tethering usage is booming (which completely blurs the lines: you can be on wifi yet using up your mobile phone's data plan), roaming costs are changing quickly trough legislation (e.g in Europe[1]), LGE is now as fast as most home wifi networks, etc.

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.

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). 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.

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.

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).

Hope this helps.

--tobie

---
[1]: http://www.theverge.com/2013/5/30/4378972/neelie-kroes-ec-net-neutrality-roaming-europe

Received on Monday, 9 December 2013 12:03:39 UTC