RE: Liaison statement from OMA on network efficiency

How about continuing the discussion, and gathering use cases for such API's in the Network Friendly WebApps CG [1]?

We did develop specifications in OMA [2] for such enablers of managed content delivery services, albeit more complex and feature-rich than I would expect W3C would need or develop. But that specification does illustrate the vision for what can be achieved when an app offloads content delivery to an underlying framework.

[1] http://www.w3.org/community/networkfriendly/
[2] http://technical.openmobilealliance.org/Technical/Release_program/dcd_v1_0.aspx

Thanks,
Bryan Sullivan 

-----Original Message-----
From: Tobie Langel [mailto:tobie@fb.com] 
Sent: Tuesday, February 12, 2013 8:28 AM
To: hi-yokota@kddi.com; SULLIVAN, BRYAN L; Dominique Hazael-Massieux; public-device-apis@w3.org; Frederick.Hirsch
Cc: Mohammed Dadas
Subject: Re: Liaison statement from OMA on network efficiency

On 2/7/13 6:30 AM, "hi-yokota@kddi.com" <hi-yokota@kddi.com> wrote:

>Hi Bryan, Dominique and all,
>
>I fully support Bryan's opinion and would like to make the network more
>visible and easy to use for WebApps for it to be able to use network
>resources more efficiently. Privacy and security issues are very
>critical; therefore must be handled carefully, but we have several tools
>to manage them. OMA, GSMA and 3GPP are working on network efficiency in
>different forms and areas. W3C should interwork with them since network
>efficiency is achieved by end-to-end. I'm wondering how we can move it
>forward...

I wrote to length about this already. Getting developers to care about the
network implies you either have a carrot or a stick.

Here the stick is a way for end-users to become aware of which website /
web app is draining their battery. This implies lobbying user agent
vendors to surface this information to the user.

The carrot is all about providing Web developers with APIs that don;t
exist know but would be awesome to have (and that let you save bandwidth).
For example, an API which would let developers download or upload large
amounts of info in the background would be awesome (use cases: upload
pics, download the weekly edition of an online magazine, etc.). Currently
this has to be done by the application itself, when it is in front of the
user's eye. A great API to do this would allow requesting a background
update whenever this is convenient (e.g. on wifi over the next 24 hours).
The user agent is in charge of the whole process and can do all bandwidth
optimization it wants to. The developer gets a new API. The user gets a
phone that lasts longer and better user experience.

There are plenty of other API that could help with your goal to lower
network congestion and that don't imply actually exposing network data
most developers do not understand or have any incentive to use, e.g.: HTTP
diffs, APIs to prefetch resources, bulk XHR requests, fixed AppCache, etc.

So to answer your question about how to move forward, I suggest you look
at ways to give carrots to developers that can benefit the network. We'll
all be better off for it. :)

--tobie

Received on Tuesday, 12 February 2013 13:40:16 UTC