Re: [Beacon] spec feedback + few suggestions

Regarding when to send the beacon or specifying a time to live for the
beacon, I wonder if it is necessary. Why not just immediately send it? It
seems like the current page is being unloaded which in most cases mean
another page is being loaded. So the radio is going to be on anyway.

I also feel the topic of optimizing battery life by batching requests needs
more thinking. It doesn't seem right to write a specification driven by
that need. If the platform changes in future, these kind of optimizations
would look quite silly.

Arvind


On Wed, Oct 30, 2013 at 4:18 PM, Ilya Grigorik <igrigorik@google.com> wrote:

>
> 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
>
>
>
>