Re: [Beacon] spec feedback + few suggestions

On Tue, Nov 12, 2013 at 5:17 AM, Ilya Grigorik <igrigorik@google.com> wrote:
>> 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.

It's impossible to make navigator.onLine reliable. The last time the
device did a ping to the radio tower it could have responded that you
are still connected, however since then you might have lost connection
without having discovered that through another radio ping.

Even when connected over wifi or ethernet you can't really implement
reliable navigator.onLine. Last time you sent a packet your
connectivity might have been fine. But since then something broke
between your router and the outside internet. You won't know that
until the next time you attempt to make a request.

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

SW won't reliably know if it's online. The suggested behavior for SW
is to use local data first. If needed you then kick off a network
request, and if that comes back with newer data trigger a refresh (of
whatever data was requested, not a full-page reload).

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

The problem is that with beacon you can't build logic to address it
due to the fire-and-forget nature.

Maybe we should add API which enables enumerating failed and/or
succeeded beacons?

/ Jonas

Received on Tuesday, 12 November 2013 00:40:57 UTC