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

On Wed, Oct 9, 2013 at 4:51 PM, Tobie Langel <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)> 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.


> >
> > > 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. 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.


>
> --tobie
>
>
>