Re: [Beacon] spec feedback + few suggestions

On Wed, Oct 30, 2013 at 11:30 PM, Arvind Jain <arvind@google.com> wrote:

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

Agree, for the "onunload" case that's likely the logic we want.


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

What kind of platform changes are you thinking about that would change
this? As a reference point, Apple is making a strong push towards APIs that
allow efficient request aggregation [1], and similarly, Android provides
"inexact polling" [2] APIs that allow you to do the same. Further, I know
that there is a strong interest in similar mechanisms for background
updates / scheduling in context of ServiceWorker + Alarm APIs. Last but not
least, some carriers even deploy their own middleware on their phones to
intercept / aggregate network activity to reduce "signal storms" in core
networks... In short, I think we have solid indicators that this is a real
problem, and one we should address in the web platform.

The use case we're trying to address with the aggregation logic is: you're
on a page, you're scrolling around, clicking on things, etc., and each
action may emit a beacon (analytics events, timing events etc) - we want to
aggregate these events and emit them in batches / when the radio is active,
instead of having to wake it up everytime.

ig


[1]
http://devstreaming.apple.com/videos/wwdc/2013/204xex2xvpdncz9kdb17lmfooh/204/204.pdf
[2]
http://developer.android.com/training/efficient-downloads/regular_updates.html#OptimizedPolling



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