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

+qsr

qsr@ informed me he emailed out about the first use case earlier and
proposed
http://lists.w3.org/Archives/Public/public-web-perf/2013Sep/0088.html.

Beacon does seem like it addresses most of this. I'm a bit curious about
the decision not to notify on completion. I guess it's done this way
because the JS environment may not be alive anymore. But this means you can
never tell if the network request completed, which I think is important.
Certainly the browser I work on keeps its own analytics and knows to track
whether those analytics stats uploads succeed. I would think we'd want to
extend this same ability to web apps. Is there any proposal to address this?

And looking at qsr@'s proposal, it also has a nice thing where it tries to
let the user agent have flexibility to issue the network request when
appropriate, but if the delay exceeds a certain timeout, then it issues the
network request anyway. I think that's a good flexibility to have. Is there
a reason not to support this?

As far as lazyload, I don't think that's right. That's about when to
schedule a network request. But the think with bulk data downloads is you
want them to happen in the background. If interactivity starts up again,
then you want to pause them and then resume later, so you don't have
bandwidth contention. Lazyload doesn't seem to provide any hint to the user
agent to know that it's kosher to pause the resource load. Does Service
Worker have any mechanism for this? I think it similarly mostly focuses on
when to issue a network request, but once that network request begins, it
doesn't have any say.

Cheers.


On Tue, Oct 1, 2013 at 1:46 PM, James Simonsen <simonjam@google.com> wrote:

> On Tue, Oct 1, 2013 at 12:23 PM, William Chan (陈智昌) <willchan@chromium.org
> > wrote:
>
>> Sorry if this has already been raised. If so, please just point me to the
>> relevant thread.
>>
>> Anyway, here are some use cases I'm looking at:
>> * Don't wake up the radio. This is not an interactive network request,
>> just fire it off whenever convenient. E.g. analytics. It's silly to wake up
>> the radio and waste power just to fire off this request.
>>
>
> This sounds like Beacon.
>
> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/Beacon/Overview.html
>
>
>> * 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), sort of like how applications like browsers auto-update. You
>> don't want this to contend with interactive browsing though.
>>
>
> This sounds sorta like lazyload. Is that good enough? Otherwise, it sounds
> like it's just a more extreme form of it.
>
> Also, this makes me think of Service Workers. Maybe we should reach out to
> them about incorporating lazyload.
>
> James
>