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

Having this be a synchronous API is going to be troublesome to implement.
Please consider doing asynchronous.

// mobile
On Dec 2, 2013 7:40 PM, "Arvind Jain" <arvind@google.com> wrote:

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