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

On 3 December 2013 03:38, 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.
>
>
>
The new draft includes a note:
> This method does not provide any information whether the data transfer
has succeeded or not, as the data transfer may occur after the page has
unloaded. To be still an effective mechanism for developers, the User Agent
should make the best effort to transmit the data including making multiple
attempts to transmit the data in presence of transient network or server
errors, even though it uses POST to transmit the data.

This is clearly a step in the right direction (the previous draft didn't
even acknowledge that network errors may occur).  However, I think the term
"best effort" is too vague.  If some User Agents' best effort is better
than other User Agents, then analytics data is going to be skewed towards
them.

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


-- 
Luke Blaney
Labs developer, FT Labs [labs.ft.com | 0870 085 2038 | @ftlabs]

-- 

------------------------------
This email was sent by a company owned by Pearson plc, registered office at 
80 Strand, London WC2R 0RL.  Registered in England and Wales with company 
number 53723.