RE: [Beacon] spec feedback + few suggestions

A bit late, but let me chime in here as well.

Typically analytics beacons are set in the onunload or unbeforeunload events. However, analytics also sends data while a page is active. Typically you do this to avoid not getting data in case when the user would simply close the browser.

You also need to think about about single page applications. Sending data on unload does not make sense in this case.

Personally it does feel a bit weird to have a functionality like this attached to an event rather the navigator object.

// Alois



Alois Reitbauer | Technical Product Manager | Compuware APM

________________________________
From: David Bruant <bruant.d@gmail.com>
Sent: Sunday, November 10, 2013 7:15:57 PM
To: Jatinder Mann; Austin, Daniel; Ilya Grigorik; Jonas Sicking; Chase Douglas; public-web-perf
Subject: Re: [Beacon] spec feedback + few suggestions

Hi,

Sorry, arriving super late to the party, but I have a few comments.

>From what I understand, there are 2 use cases:
1) frequent beacon
2) send data on unload

The first use case is about being able to batch requests to save battery on mobile. I wonder if it wouldn't be better suited to standardize a request scheduler, that would also work for XHR (and why not everything that performs network requests). For instance, the author would provide a bunch of requests with constraints (send such requests within x secs) to the UA and the UA would send the requests as felt most appropriate.

Only the second use case would remain.

Le 07/11/2013 01:11, Jatinder Mann a écrit :
- sendBeacon is on navigator, not window
In case agreement is reached on the point above and only the second use case remains, the sendBeacon function could be attached to the unload event object:
    window.addEventListener('unload', function(e){
        e.sendBeacon("/log", data);
    });

- url parameter comes first, method parameter is optional with "GET" default action
I agree with Jonas that POST is a much better default, especially given that the response can't and won't be processed by the client. No problem with keeping GET as an option, though.

- Data transmission is limited to 10KBs.
I'm balanced on this one. I've read the discussion and understand the implementors point of view, but I worry it may mean authors will revert back to sync XHR for the unload case when they want more than 10KB, which would be a sort of square one return.
Do UAs already set a limitations on how much can be sent on unload sync XHR? I feel it would make sense to align what's possible with sendBeacon with what's possible with unload sync XHR (in one way or the other).

Thanks,

David
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Compuware Austria GmbH (registration number FN 91482h) is a company registered in Vienna whose registered office is at 1120 Wien, Austria, Am Euro Platz 2 / Gebäude G.