Re: Beacon API

On Fri, Feb 15, 2013 at 3:06 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> Just to be clear. I understand why we'd want this. I'm a) wondering
> why it'll be successful this time given it has the same
> characteristics as ping="" b) asking about the desired timeframe given
> the highly likely introduction of a new Future-based API for fetching.
>

To echo Ian's comment: I wouldn't consider ping a failure, and I think it
can still be a success.. If nothing else, the practical problem is that its
not universally supported, hence sites that must rely on it must implement
the manual fallback anyway, at which point many just stick with that -
outbound link tracking is an annoying problem that shouldn't exist.

Also, I think while what we're discussing here is similar in principle, the
use case is actually very different.

With <a ping>, the action is initiated by the user. What we're asking for
here is for "out of band" request semantics for actions initiated via JS. A
good example is any form of passive audience measurment on a page, in a
game, in an app, etc. The millions of real-time analytics beacons is just
one example: these could be aggregated and handled much more efficiently,
which would be a huge win on mobile. Similarly, same semantics extend to
"on unload" cases covered earlier.

Further, perhaps with a bit more thought.. it would also be possible to
tackle the use case of aggregating background polling pings (this would
require callback support, but can be restricted to requests which occur
while the page is active only). For example: two background apps, each
periodically polling for updates. Each submits a polling request with defer
flag.. the two are bundled by the browser and issued back to back, waking
up the radio once, as opposed to (potentially) twice.

ig