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

I would like to voice my satisfaction with the XHR extension proposal. I
second that even though XHR may not be the "best" API, it is well
understood and already wrapped by most frameworks. Further, one can hardly
knock it in the greater realm of APIs. It's really not that bad :).

On Tue, Dec 3, 2013 at 9:46 AM, Ilya Grigorik <igrigorik@google.com> wrote:

>
> On Mon, Dec 2, 2013 at 7:56 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>
>> > var xhr = new XMLHttpRequest();
>> > xhr.detach = true; // or some such...
>> > ...
>> > xhr.open('GET', '/path');
>>
>> I always felt that the main argument for not using the XHR syntax is
>> that the XHR syntax sucks. And most of it is there in order to provide
>> progress and result notifications, which I think we should avoid.
>>
>
> Regardless of how pretty it is, it is well understood and is already in
> use by all the major vendors.. As such, I think the adoption delta is
> actually smaller with XHR than with a brand new API.
>
>
>> > In theory, this could provide following semantics:
>> > - marking request as "detach" forces it to be async (i.e. can't do sync
>> XHR
>> > with detach=true)
>> > - detach is functionally equivalent to XHR, callbacks and all.
>>
>> I explicitly do not want to provide any callbacks. That will limit the
>> UAs ability to be smart about when the beacon is sent. I.e. the more
>> information about when a beacon is sent that we expose, the larger the
>> risk that pages will break as implementations change when the beacon
>> is sent in order to save battery.
>
>
> So, my proposal is to simply ignore any/all callbacks *if* the parent page
> is gone:
> - You fire a regular XHR with detach = true
> - If the request completes while the host page is alive, your callbacks
> are invoked
> - If the host page is gone then no callbacks are executed (e.g. UA sends
> headers + payload and then moves on)
>
> This is effectively the behavior that you get today if you fire an async
> XHR within the unload handler: it's a race condition between request being
> emitted and it being cancelled.. in either case, unless you have a *very
> slow* onunload handler, your callbacks never fire. Effectively, all this
> does is allows the request to "complete" (the headers and body to be sent),
> without it being cancelled by the UA when the page is being unloaded. As a
> bonus, this is useful beyond just analytics beacons.
>
>