Re: [Beacon] spec feedback + few suggestions

On 9 November 2013 18:15, Ilya Grigorik <igrigorik@google.com> wrote:

>
>  > What's the use case with timeouts?
>>
>> The usecase is that if you are sending a beacon to track "user clicked
>> an ad in the bing search results", then you want to really not lose
>> track of that click since it is what makes you money. So you'll want
>> to use a long timeout, like a day or two.
>>
>> But presumably there are use cases for when the data is no longer
>> important if it wasn't submitted after a few minutes. I don't actually
>> have any examples of this, but I think Ilya did.
>>
>> I definitely think that if the timeout is reached, we should drop the
>> message on the floor and *not* notify the page. So it should be a
>> mechanism for doing retries. I.e. the timeout means "the data is
>> useless after this point", not "need to try something else after this
>> point".
>>
>
> FWIW, I think this logic should be deferred to the server - if the
> delivered beacon is no longer useful due to the long delay since it was
> first emitted, the server can just drop it on the floor. Yes, not sending
> the data saves the extra request, but presumably the payload is small so
> the request overhead is not large, and this keeps the spec/implementation
> simpler.
>
> 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.

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


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


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

-- 
Luke Blaney
Labs developer, FT Labs [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.