Re: [Beacon] spec feedback + few suggestions

> Besides, to take a step back.. I think we should treat sendBeacon() as a
>> "short-delay" mechanism: the beacon may be delivered immediately, or within
>> short delay of when it was dispatched. I don't think we need to or should
>> tackle the larger "offline" use case.. there are other mechanisms for that
>> - i.e. ServiceWorker.
>>
> I don't think you can just simply rule out "offline" as a separate use
> case.  With more and more people accessing the web over mobile, it's
> increasingly harder to establish whether someone is "online" or "offline"
> at any given moment.
>

Perhaps poor wording on my part. I'm not making an argument that "offline
does not matter". Rather, I'm saying there are other mechanisms in the
platform that are specifically designed and should address this problem -
beacon does not need to tackle this problem on its own.


> - your app should use navigation.onLine to first check status of
>> connection and fallback to own logic to aggregate offline beacons (e.g.
>> your analytics library can do this on your behalf by logging to
>> localStorage or equivalent).
>>
> navigation.onLine isn't reliable.  It just means that the device thinks
> it's connected to something. That something could be a wifi router with no
> internet connection, a 3g connection with such high latency that no
> requests succeed or a captive portal.  By no means does it mean that any
> given future request is going to succeed.
>

If navigator.onLine isn't reliable, then that's a bug and it should be
addressed at that layer.


>  - if app was online when beacon was emitted, but then goes offline
>> before it was delivered, we have ServiceWorker.. it can intercept the
>> request and <apply your logic>.
>>
> A ServiceWorker can't predict whether a request is going to succeed any
> better than javascript calling ajax can.  So to see whether a request
> actually succeeded, the ServiceWorker would need to look at the response of
> the beacon request coming back from the server.  Doesn't this defeat the
> whole "fire-and-forget" idea behind beacon?
>

SW will obviously need a mechanism to distinguish whether the UA is online
or offline.. if it doesn't, then what's the point of SW? Once again, this
is not a problem for Beacon to solve -- SW sits at a layer below it and we
should defer this logic to SW.


>  - if the UA is offline and gets a sendBeacon(), it can hold it for some
>> short period of time (with hope that UA will come online shortly), and then
>> release it regardless of connection state.. if there is no SW to intercept
>> it and the UA is offline, then beacon is dropped.
>>
> Seeing as one of the primary use cases for this is analytics, I don't
> think many people will be happy with requests being dropped.
>

This is no worse than what happens today - e.g. your connection drops, your
beacons drop.. unless you've built additional logic to address this.


>  In short, I think we should defer offline handling to the application and
>> simplify the sendBeacon promise to: we will attempt to deliver all queued
>> beacons within 0-x seconds; if delivery fails, the beacon is dropped.
>>
>> It sounds like what you're proposing is the equivalent of sending all
> analytics data over UDP.
>

Not at all. It's functionally equivalent to what you use today, but more
efficient, and defers the complicated offline cases to APIs that are
specifically designed to deal with those cases.