Re: [Beacon] spec feedback + few suggestions

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

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

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.