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

On Mon, Nov 25, 2013 at 7:43 PM, Ilya Grigorik <igrigorik@google.com> wrote:

> (forking thread)
>
> On Fri, Nov 22, 2013 at 6:38 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>
>> On Fri, Nov 22, 2013 at 5:19 PM, Jatinder Mann <jmann@microsoft.com>
>> wrote:
>> > The WG discussed whether we should apply a limit to the number of
>> beacons
>> > that can be sent or the size of the beacons sent. While we had initially
>> > considered a limit of 10KBs, after some discussion, we saw real world
>> > examples of much larger data being sent. We eventually decided to not
>> limit
>> > the size of the beacons, as limits set now may not feel rational years
>> from
>> > now. We opened ACTION-114 - Update beacon spec to have no limits, no
>> retry
>> > logic, no batching, post is the only method to track this.
>>
>
> I hesitate to re-open this can of worms, but... If there are no enforced
> limits, no batching, no retries, and so on, then do we need an entire new
> interface for beacon? These restrictions were the primary reason (to me) as
> to why we needed/wanted a separate interface. Also, I'm not sure why given
> no restrictions on any of the above we then limit it to POST only -- seems
> inconsistent.
>
> Assuming we drop all of the above restrictions, then the only new feature
> here is that the request can be "detached" from the parent page - i.e. if
> the page then transitions to onunload / tab is closed, then the request
> does not hold up the event and is not cancelled. With that in mind, this is
> more simply expressed as:
>
> var xhr = new XMLHttpRequest();
> xhr.detach = true; // or some such...
> ...
> xhr.open('GET', '/path');
>
> 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.
> - if parent page is gone by the time XHR completes, callbacks are not
> fired.. otherwise, callbacks fire as a regular XHR would.
>
> In short, detach could be a flag that provides a simple insurance policy:
> this request should not block onunload and it should continue past
> onunload. However, if request completes after the parent page has been
> unloaded, no callbacks are fired... This also implicitly means no retries,
> etc.
>
> An upside of such mechanism would be that it is trivial to retrofit on top
> of millions of currently deployed beacons which rely on XHR: just add
> 'detach=true' and you're done.
>
>
That seems like a huge benefit for authors. No need to learn a new API
(even if sendBeacon is not highly complicated) is also a benefit.

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.