W3C home > Mailing lists > Public > public-device-apis@w3.org > December 2012

Re: Network Information API

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>
Message-ID: <F9981AFB970564408FEB7DFCF62D4408436D732E@PRN-MBX01-4.TheFacebook.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 12 December 2012 17:01:23 GMT