RE: [Beacon] spec feedback + few suggestions

Based on feedback on this thread, I've updated the latest editor's draft [1] with the following changes:

- Beacon method is renamed to sendBeacon
- sendBeacon is on navigator, not window
- url parameter comes first, method parameter is optional with "GET" default action
- cross-origin transmissions cannot use "PUT" method
- Added details on UA "best effort" attempts
- Data transmission is limited to 10KBs.
- Updated errors to URLMismatchError, SecurityError, QuotaExceededError instead of SyntaxError
- Updated Processing Model to match spec behavior
- Updated abstract to remove "user agent taking the responsibility to eventually send the data"
- Updated Ack section

I've also opened Action 111: Determine appropriate size limit for beacon data based on current usage patterns [2] to help us determine what the right limit should be for beacon data transmissions and whether we should set a limit on number of beacons per page or rate at which beacons are transmitted. Ilya, you had mentioned that you were going to look at Google Analytics data to see what the common analytics package sizes are? That data will go a long way in helping us determine an appropriate limit.

I think we need to close on how we want to deal with failures, see mail thread [3]. Currently, the spec doesn't go into the expected details on what to do if the beacon has failed to be sent or received for whatever reason. I personally rather we keep this behavior as implementation details and let the quality of implementation determine how often it will retry. However, it may make sense to put in some recommendations in the spec so we have interoperability. As Luke mentions, if one UA always sends the analytics by aggressively retrying but another doesn't, the analytics data may be skewed, which may hurt the adoption of this method.



Received on Thursday, 7 November 2013 00:11:43 UTC