Re: Network Information API

Hello Tobie and all,

(If this e-mail does not appear on the ML, please post it for me)

I think that the Network Type would be as much useful as bandwidth for Web applications (apart from some privacy issue). Some operators require their own 3G or LTE networks for security reason (e.g., for charging or for delivering operator-owned content) or for quality reason (QoS of 3G/LTE networks is more predictable for them). It would be more convenient for those applications to know what type of networks are used than just waiting forever with some ambiguous error messages.

The available bandwidth is useful for some cases, but it is getting more difficult to infer the network type now that LTE is available, which is as fast as WiFi. I think that the precise figure is not necessary for most of the cases, but just enough to know how long it will take to download some content like 1 second, 1 minute or 1 hour...

Regards,
--
Hidetoshi
 

> -----Original Message-----
> From: Tobie Langel [mailto:tobie@fb.com]
> Sent: Thursday, December 13, 2012 2:01 AM
> To: Niklas Widell; 'Yoav Weiss'
> Cc: SULLIVAN, BRYAN L (bs3131@att.com); public-device-apis@w3.org
> Subject: Re: Network Information API
>
> 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 Tuesday, 18 December 2012 07:21:42 UTC