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

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

>