- From: Ilya Grigorik <igrigorik@google.com>
- Date: Wed, 30 Oct 2013 16:18:45 -0700
- To: Jatinder Mann <jmann@microsoft.com>
- Cc: Chase Douglas <chase@newrelic.com>, public-web-perf <public-web-perf@w3.org>, Jonas Sicking <jonas@sicking.cc>
- Message-ID: <CADXXVKoe+HitEw5m0jMuETWJPL1nMaOHEZ0s5efUz-YXmpByjg@mail.gmail.com>
On Wed, Oct 30, 2013 at 3:50 PM, Jatinder Mann <jmann@microsoft.com> wrote: > 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. > Re, best effort: Agree with Jonas. If anything, we can revisit this later. If we think that "best effort" will be relatively quick (max: minutes), then I think we can define a single recommended flush limit - e.g. in case of onclick, we should be sending beacons immediately since the radio is already active, but if we're collecting event beacons as user is interacting with same page (without triggering the radio), then I think we should be flushing this queue relatively frequently (once a minute or so). I do think we need to provide this sort of guarantee to ensure that real-time analytics (one of the biggest offenders when it comes to battery life) leverage Beacon. Also, if we flush the queue within reasonably short intervals, the "best effort" part becomes much easier -- we lower the likelihood of lost beacons due to connectivity changes, etc. As far picking the actual number, once a minute? Alternatively, we could provide a slightly more elaborate API which allows you to set a "send within" parameter but with a minimum floor. For example: navigator.sendBeacon("http://beacon-collector.com/report","someEvent=true", {method: "POST"}, { within: 300 // min: 60s, default: 120s (or some such) }) If I have a high priority update, then I can lower the within interval, and the default interval is some multiple of the min.. Thoughts? ig
Received on Wednesday, 30 October 2013 23:19:57 UTC