W3C home > Mailing lists > Public > public-web-perf@w3.org > October 2013

Re: [Beacon] spec feedback + few suggestions

From: Ilya Grigorik <igrigorik@google.com>
Date: Wed, 30 Oct 2013 16:18:45 -0700
Message-ID: <CADXXVKoe+HitEw5m0jMuETWJPL1nMaOHEZ0s5efUz-YXmpByjg@mail.gmail.com>
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>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:37 UTC