Re: [Beacon] Interaction with Service Worker

On Mon, May 19, 2014 at 11:13 AM, Ilya Grigorik <igrigorik@google.com>wrote:

> +jake, alex
>
> On Fri, May 16, 2014 at 5:14 PM, Kornel Lesiński <kornel@geekhood.net>wrote:
>
>>
>> It's not immediately obvious how the beacons should be "seen" by Service
>> Workers and how UAs should interact with them, so it'd be nice if the spec
>> gave some guidance about this.
>>
>> My suggestion is:
>>
>> The Service Worker should be able to intercept beacon requests. The
>> implementation of service worker should forward these requests immediately.
>> Even when Service Worker is used, the UA should still be in charge of error
>> handling and when it decides to retry sending the beacon it should make
>> another request.
>>
>
> I think that's implicit. All network requests should pass through SW, not
> sure we need a special carve out?
>

I'm pretty sure we *don't* need a special carve out.


> Basically, just passing the request through should be an ideal
>> implementation of the service worker.
>>
>> The alternative would be to make Service Worker responsible for queueing
>> and retrying beacon requests, which may seem like a good idea at first.
>> However, IMHO, that would be a sharp jump in difficulty for authors:
>>
>> - authors would have to reinvent UA's logic for managing network
>> traffic/priorities and strategy for optimal use of cellular radio power.
>> That's currently not even possible, and even if it was, that's a pretty
>> complex problem to throw at authors.
>>
>> - authors may use Service Workers for other reasons than interception of
>> beacons, so reliability of sendBeacon should not be negatively affected by
>> mere presence of a Service Worker.
>>
>> - having simple, useful default behavior without reliance on a service
>> worker is very useful, and doesn't stop authors from implementing
>> additional logic in the SW if they wish.
>>
>
> It seems like, at the very least, there should be some special flag on the
> beacon request, such that SW could identify beacon requests and carve out a
> special path for them? That would allow you to inherit default sendBeacon
> logic implemented by the browser. Alternatively, SW could synthesize a 200
> response and then "roll its own" logic?
>

SW's are additive. They aren't required for normal operation, either for
Beacon or for regular XHR-like requests. To the extent that they interact
with beacons, it'll need to be via lifetime extension for the onfetch event
that gets sent as a result of the beacon, but this isn't any different to
how other requests work.