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:
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/Beacon/Overview.html

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 <igrigorik@google.com> wrote:

> On Wed, Nov 27, 2013 at 9:40 AM, Yoav Weiss <yoav@yoav.ws> 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 <johnme@google.com> 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).
>
>>