- From: Tobie Langel <tobie@fb.com>
- Date: Wed, 12 Dec 2012 17:00:53 +0000
- To: Niklas Widell <niklas.widell@ericsson.com>, "'Yoav Weiss'" <yoav@yoav.ws>
- CC: "SULLIVAN, BRYAN L (bs3131@att.com)" <bs3131@att.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
Applications use the network to send and receive data. Sometimes this data needs to be sent or received immediately. For example, a purchase order for stock can't wait. Sometimes it doesn't really matter when this data gets sent, provided it's in a reasonable enough timeframe. For example, syncing pictures from a local camera app to the cloud can happen once everyday. Sometimes, it doesn't even matter whether the data is received or not. For example, pre-fetching data makes the experience better, but failing to do so doesn't cause you to loose critical information (it could be a pain if you're offline, however). Networking has associated costs (battery, bandwidth, encryption/decryption, etc) which are highly device and context dependent. An application draining your battery has very different consequences when lost in the jungle than it has when you're sitting at home within arm's reach of a charger. Similarly, roaming costs affect students abroad very differently then they do millionaires. The list goes on. Currently, application developers have no incentives to make their applications more friendly to the device and the user's resources. Were it possible to provide such intensives (through curated app stores, or what not), developers would still be at loss as to how to cater for the wide variety of contexts outlined above without asking for user input. Input which users would have to provide, again and again to different applications. Instead, what we really need to look at is to precisely define the use cases faced by users and developers and provide APIs for those. And then let the user agent fine tune how it handles networking based on information it receives from sensors, user input, etc. and which isn't necessary for the application to be aware of (granted it could even be a privacy issue). For example, one could imagine an API to prefetch content, or an API to upload large files (e.g. photographs) within a certain period of time and call a WebWorker once done (or timed-out). The benefits are manifold. First of all, developers don't have to understand implementation details of the networking protocols their app is currently using. Instead they can convey intent ("it is critical to send this data now", "I might need this in the future", etc.). Secondly, there's a real incentive for developers to use these APIs as it opens up features they did not have access to previously (background sync, etc.). Thirdly, user agents / devices are able to fine tune how to best handle this traffic, which is good as they are the ones that will get blamed for high bandwidth usage or draining batteries. Fourthly users can decide at the user agent level when and how to allow prefetching, background sync, etc. (and special case certain apps where necessary). Thanks for your time if you made it that far, --tobie >
Received on Wednesday, 12 December 2012 17:01:23 UTC