Re: [beacon] no limits, no retry, no batching, post only

I uploaded a new version of the draft here to address some of the feedback
so far on the thread at at TPAC:

It is still its own draft. We can decide on the behavior here and then
decide whether it fits into XHR or not.

On Mon, Dec 2, 2013 at 11:25 AM, Ilya Grigorik <> wrote:

> On Wed, Nov 27, 2013 at 9:40 AM, Yoav Weiss <> wrote:
>>> One of the features previously discussed regarding the beacon API is the
>>> ability to be "radio friendly", and send the beacon only at the next time
>>> that the radio wakes up on mobile connections. Is this capability off the
>>> table for the beacon API?
>>  That capability can also be beneficial for radio-friendly data syncing,
>>> where "detach" makes no sense, so I'm not sure if it should be as part of
>>> the beacon spec, or as a separate one. OTOH, it can also be an attribute on
>>> XHR, defaulting to false.
> Right, I think that's an important observation. Having the request (a)
> stay alive beyond page onunload, and (b) be delayed / aggregated / batched
> are independent requirements, and arguably shouldn't be be coupled
> together. As such, having two separate XHR flags would certainly make sense.
> That said, before we go too far down this path, I think we should first
> clarify whether there is agreement on dropping size and number of requests
> restrictions. I share Jonas's concern over large uploads interfering
> with/after page onunload.. That said, if someone wants/needs to do that,
> they'll probably still do it, except they'll invoke a sync XHR (or similar
> hack) and block onunload, just as they do today...
> Speaking for myself, and despite the fact that I was advocating for these
> limits earlier, the more I think about the XHR flag, the more I like it:
> it's simple, intuitive, and it is useful beyond just beacons. For example:
> I hit send in my online mail application and then immediately close the tab
> - did the send notification make it to the server? No idea... as there is a
> race condition. But if we allow the XHR to be marked as "detached", then
> this case is easily addressed.
> On Wed, Nov 27, 2013 at 6:26 AM, John Mellor <> wrote:
> What exactly does "no retry" mean? Detachable XHRs have the potential to
>> enable powerful use cases like composing an email offline, and having it
>> sent in the background next time the device goes online.
>> Does that require retries? Or even with no retry, would the UA at least
>> wait until the network connection was working (and not behind a captive
>> portal) before trying to send the detached XHR?
> FWIW, I think this is beyond beacon / detach. What we're talking about
> here is allowing the request to persist beyond onunload, not buffering
> requests while offline... To address offline you should use SW /
> navigator.onLine to detect your state and adapt accordingly - i.e. if you
> make a "detached" XHR request while offline, it'll just fail like any other
> XHR (modulo SW logic).

Received on Tuesday, 3 December 2013 03:39:17 UTC