Re: is anyone looking at specifying something for background requests/downloads?

On Oct 10, 2013, at 2:01, "William Chan (陈智昌)" <willchan@chromium.org<mailto:willchan@chromium.org>> wrote:

On Wed, Oct 9, 2013 at 4:51 PM, Tobie Langel <tobie@w3.org<mailto:tobie@w3.org>> wrote:
On Wednesday, October 9, 2013 at 10:23 PM, William Chan (陈智昌) wrote:
> On Thu, Oct 3, 2013 at 6:49 AM, Tobie Langel <tobie@w3.org<mailto:tobie@w3.org> (mailto:tobie@w3.org<mailto:tobie@w3.org>)> wrote:
> > +Alex
> >
> > On Tuesday, October 1, 2013 at 1:23 PM, William Chan (陈智昌) wrote:
> > > * Downloading a large chunk of data in the background. Let the user agent know that if there's contention, this network request should yield to any interactive one. E.g. web apps can download their next version (which may be large).
> >
> > So this particular use case seems already possible with ServiceWorkers[1] as an implementation-specific optimization.
>
> I ran into Alex at the office last week and we chatted a bit about ServiceWorkers. I don't recall him mentioning this. Can you mention what specific part of ServiceWorkers addresses this? I don't see anything indicating the nature of the network request so the user agent can pause these bulk network requests so they don't contend with interactive ones.

I'm assuming the ServiceWorker responsible for caching could be run at any point in time by the UA without requiring the user to navigate to the related application. This optimization can be done with AppCache, I would expect ServiceWorkers to support it too.

I see. Yes, I do understand that to be a goal of ServiceWorker, to be able to run at any point in time and be killed at any point in time. But the key thing that is missing, and which I'm lobbying for, is adding an attribute to network request so the UA can understand that it's a background bulk upload/download, and the UA should try reduce the bandwidth utilization for that request when other, more important (interactive) requests are present, so that there's less contention. I think this is a different knob from what ServiceWorkers offer.

So in that particular scenario, such am attribute is unnecessary: the UA initiated the request; it knows this request should be lower priority.

> > That said, I think there are similar use cases that would not benefit from this optimization and would need a dedicated solution. For example, a newspaper web application might want to bulk download todays news overnight, so that the application has fresh content to display when it is visited by the user on his network-less commute the next morning. Bulk uploads (e.g. uploading pictures overnight while on the home Wifi network) have similar requirements. I don't think ServiceWorkers, in their current incarnation, would support that. Alex (Cc'ed) would know.
>
> I'm probably missing something due to my relative unfamiliarity with these issues, but why isn't a timer-based XHR appropriate for prefreshing the caches?

Not really. The application layer shouldn't be the one deciding when to run the download. The OS, UA and/or the user should be making that choice based on information that shouldn't need to be surfaced to the application.

I agree in general, although I don't understand how to achieve the goal of "download todays news overnight" without a timer to indicate when to start downloading the news.

Have a dedicated API, e.g.: fetch([url, ...], timeout).

The UA has a window during which it can operate after which the request is cancelled or forced or the user pinged.

As I said above, we still need an attribute on the request to indicate that it's a bulk download at background priority, so the UA can delay/pause/resume the network request as it pleases.

Only if you don't have a dedicated API.