Re: [Beacon] Interaction with Service Worker

So I assume there's nothing specific to SW that we need to add to the spec.
Is that right?


On Mon, May 19, 2014 at 5:14 PM, Alex Russell <slightlyoff@google.com>wrote:

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