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