RE: [network-info] expressing intent (was: [minutes] Dec 11 teleconf)

Following TPAC 2012, in which I led a breakout session "Smarter Webapps for Smarter Phones" (http://www.w3.org/wiki/TPAC2012/smarterwebapps), there was renewed discussion about the Network Info API. As before, the discussion revolved around "we need network details!" vs "you might abuse them!" and got nowhere. At one point Tobie mentioned a different approach (http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/0046.html), which I had separately been thinking about, related to work in the OMA on the "Always Online Infrastructure" (AOI) service enabler specifications - which being Push-related in principle, I though really should also address some "pull"-based needs for efficient, always-on apps. But I thought it would be best if that was addressed first as an API in W3C, which could be bound (as the Push API is intended to be currently) to a diversity of platform-specific request processing services, and as an extension perhaps to XHR. So what Tobie mentioned aligned pretty neatly with what I have been considering. Not much has happened in the interim, though I've continued to socialize the idea at various W3C meetings.

So, to update and explain the idea:

At least somewhat-addressing the privacy concerns (which as explained below, I really don't share) with the network info API may be achieved by taking a more abstract service approach. At least some use cases for wanting to know when a particular type of network is available or connected have to do with wanting to defer retrieval of content until a suitable bearer is available (e.g. free, and high-BW). To do this, apps could watch navigator.online and when online=true send a beacon/ping request via XHR to their server, and use source IP address mapping to infer what type of network is in use. That's certainly possible, but keeping up with constantly updating IPV4 assignments (which may be resolved with IPV6) is a real pain, although there may be APIs somewhere to get at that "network type" info. As another approach, it would be really cool if XHR allowed apps to say "I'd prefer WiFi for this request". Certainly it would be possible to infer when the request completes, that the user is on WiFi - bringing you back somewhat to the privacy issue. But as noted above, there are perfectly plausible (at least for specific networks) app-level methods to do the same thing. So as compared to the current / network-opaque environment, is the privacy risk any greater if the app doesn't know exactly when WiFi is available, but that an earlier request for delivery over WiFi was completed?

Other use cases though don't necessarily need a specific bearer, just knowledge of when a network connection is active. Such a use case is an app that has non-time-critical requests to send, and being a good "power saving" citizen, will wait for an active radio connection (meaning for PLMN radio resource control (RRC) in full power mode) before issuing the request. Navigator.online as before is a feasible solution (though not without quirks), but apps would have to build their own "listener" javascript to queue requests and wait to send them until online=true. It would be cool if XHR instead provided apps with a way to say "I can wait x seconds for this request to be served".

To address these two types of use cases, we can describe a hypothetical new XHR extension “fleXHR” with WebIDL definition:
[Constructor] interface fleXHR : XMLHttpRequest {
 attribute unsigned short latency; // Maximum desired latency, in seconds
 attribute string bearer;                     // Ordered list of preferred bearers: one or more of "wifi", "lan", "plmn"
}

Code of an app that can accept slow/delayed delivery for a resource
flexhr = new fleXHR();
flexhr.open('GET','http://bigfiles.org/huge.mp4');
flexhr.latency = 3600; // I can wait an hour
flexhr.bearer = "wifi,plmn"; // I prefer WiFi but can accept PLMN (mobile networks)
flexhr.onreadystatechange = function() {
 if (xhr.readyState === 4) { // DONE
   /* do something useful with the data */
 }
};
flexhr.send();

The browser is then responsible for queueing the request until a suitable bearer is available, and for holding the request up to an hour, after which it would return an error to the app (TBD).

Thanks,
Bryan Sullivan

-----Original Message-----
From: Tobie Langel [mailto:tobie@w3.org] 
Sent: Wednesday, December 11, 2013 9:00 AM
To: Dominique Hazael-Massieux
Cc: public-web-mobile@w3.org
Subject: [network-info] expressing intent (was: [minutes] Dec 11 teleconf)

On Wednesday 11 December 2013 at 17:48, Dominique Hazael-Massieux wrote:
> bryan: there was a discussion a while back in DAP about taking
> a different approach
> ... which I intend to bring back in this thread
> ... an app could indicate what it's OK with: I'm OK with
> delayed transaction to benefit from newly available bearers
> ... another approach: if you have a shared connection among
> several apps with aggregate transport
> ... this might address a number of the things that app
> developers might need
> ... somewhat different approach: not obtaining info, but
> expressing intent
> ... I'll try to summarize it for the current discussion

Very keen on hearing more about this, Bryan. 

I think this approach is very much aligned with what I've been pushing lately, which is to offer developers a wider set of tools to express their needs (e.g. the user might need this resource in a little while, the UA can prefetch it if it's in a favorable position to do so) and thus allow implementors to optimize network usage and battery consumption.

It would be great it you could summarize (or point to) previous discussions on the topic.

--tobie

Received on Friday, 13 December 2013 04:36:09 UTC