Re: Network Information API

On 12/12/12 17:00, Tobie Langel wrote:
> 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).

I'm not sure I understand what is the intent of this message. Do you
think we should stop working on the Network Information specification
and create other APIs instead?

I completely agree that the API you listed would be useful. Actually I
think Yandex did a proposal for a prefetch API (though, I think appcache
should be able to handle that) and Jonas and I though about a
synchronisation API for Firefox OS but was postponed.

Although I agree with you regarding the usefulness of those APIs, I am
not sure they would make the Network Information API useless. For
example, how would you handle the use case of a game that has to pick
low or high definition textures?

--
Mounir

Received on Thursday, 24 January 2013 16:35:59 UTC