RE: [Beacon] spec feedback + few suggestions

From: Luke Blaney <luke.blaney@ft.com>
Sent: Tuesday, November 12, 2013 3:20 AM
To: Jonas Sicking
Cc: Ilya Grigorik; Jatinder Mann; Chase Douglas; Austin, Daniel; public-web-perf
Subject: Re: [Beacon] spec feedback + few suggestions

I agree with what Jonas says about online/offline.  Anyone who has written websites for use over mobile networks will tell you that the only way to be absolutely certain that a request was successful is to look at its response.

The way I see it is that there are 3 options for handling failure:
1) Don't handle failure. (Assume that all requests which were sent, eventually get received.)
2) Allow the developer to handle failure. (eg callbacks, through a ServiceWorker or enumerating failed beacons)
3) Get the User Agent to handle failure.

[Alois] I think we want behaviour one. This is inline with the idea of fire-and-forget. In many cases analytics data is also more or less real time. Having data more than a couple of minutes later does not actually add value as the data at some point would not be processed any more anyways.


Number 1 only works if your network is 100% perfect, or you don't care about losing an unknown amount of data (not ideal for analytics).

[Alois] Analytics tools can handle this today. In many cases losing a single event isn't an issue.  In the end losing data should not be the default case.

Number 2 goes against the whole notion of fire-and-forget.

[Alois] Yes, and this was a primary use case.

Number 3 would require a standardised definition of what exactly we count as "failure".

[Alois]  The biggest problems I have with the failure retry approach is that it will add overhead also on the analytics logic side. Worst case the analytics code of a page would keep trying to send data although the page has been closed minutes ago.


Obviously you can have combinations of the above, (eg "try number 3 for x seconds, then do number 1"), but then you'll end up having to deal with the problems of both of the options you've combined.



On 12 November 2013 00:39, Jonas Sicking <jonas@sicking.cc<mailto:jonas@sicking.cc>> wrote:
On Tue, Nov 12, 2013 at 5:17 AM, Ilya Grigorik <igrigorik@google.com<mailto: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



--
Luke Blaney
Labs developer, FT Labs [labs.ft.com<http://labs.ft.com> | 0870 085 2038 | @ftlabs]


________________________________
This email was sent by a company owned by Pearson plc, registered office at 80 Strand, London WC2R 0RL.  Registered in England and Wales with company number 53723.
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Compuware Austria GmbH (registration number FN 91482h) is a company registered in Vienna whose registered office is at 1120 Wien, Austria, Am Euro Platz 2 / Geb?ude G.