RE: [Beacon] spec feedback + few suggestions

On Oct 30, 2013 2:31 PM, Ilya Grigorik wrote:
> I think the above is too broad, and should be scoped to something like: "... to asynchronously transfer
> small (<TBD KB) HTTP payloads (typically, analytics beacons) from the user agent to a web server ..."

I agree that the current abstract is a bit too broad. I'll update it.


On Oct 30, 2013 2:31 PM, Ilya Grigorik wrote:
> Large background uploads are a liability for the UA and something that we don't want to allow -- the app
> should handle large uploads, and there are parallel efforts (ServiceWorker, Alarm API) that are much better
> suited to tackle this problem. On the other hand, we do know that there are a lot of small HTTP transfers
> (typically, analytics related) which if made async would have significant positive impact on web performance -
> that's what we need to solve in this spec.

Agreed.


On Oct 30, 2013 2:31 PM, Ilya Grigorik wrote:
> I would be careful with calling AsyncSend() because I think it overpromises on functionality.
> ...
> As far as the name goes, I'm not attached to Beacon, but I do think it should feel different enough to capture the
> above semantics.

We can keep the function name as beacon or sendBeacon for now and wait until we hear a better name.


On Oct 30, 2013 2:31 PM, Ilya Grigorik wrote:
> Perhaps one thing to consider is to provide some guidance on possible delays. For example, if I want to use
> Beacon for ~real-time analytics, small delays (on the order of 0-300s) may be acceptable, but I wouldn't want
> to get the notification 15 minutes after the fact. A simple strategy would be: deliver beacons next time the radio
> is available, or flush the beacon queue every X seconds.

Do you think "best effort" is good enough? On the other thread, there is an idea of passing in a timeout argument after which the user agent won't attempt to send the data. At least you'll know it's a failure if you haven't received the data in that window.


On Oct 30, 2013 2:31 PM, Ilya Grigorik wrote:
> Right, exactly what we're trying to guard against.. Don't have a number yet, but I've reached out to the Google
> Analytics team to see if they can provide some stats on what they see for their pings.

It would be great if we can base our limit on data.

Jatinder