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

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?

Similarly I'd have thought that getting notified of clicks on ads while
offline also requires a reliable delivery mechanism...


On Wed, Nov 27, 2013 at 9:40 AM, Yoav Weiss <yoav@yoav.ws> wrote:

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