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

Re: Beacon API

From: Mark Watson <watsonm@netflix.com>
Date: Fri, 15 Feb 2013 20:44:28 +0000
To: Jonas Sicking <jonas@sicking.cc>
CC: Arvind Jain <arvind@google.com>, Ilya Grigorik <igrigorik@google.com>, Jatinder Mann <jmann@microsoft.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>, "Reitbauer, Alois (Alois.Reitbauer@compuware.com)" <Alois.Reitbauer@compuware.com>
Message-ID: <7FA8E7A9-BCC9-4554-83E2-D0C24CF317AB@netflix.com>

On Feb 14, 2013, at 11:55 PM, Jonas Sicking wrote:

> On Thu, Feb 14, 2013 at 5:17 PM, Arvind Jain <arvind@google.com> wrote:
>> Are there other use cases besides Analytics?

Yes. We use synchronous XHR during close (actually in onbeforeunload) in our video streaming service to ensure we have a record of when the streaming session ended on our application servers (which are different from the streaming servers - the streaming servers are dumb HTTP servers in a content delivery network).

There is information in our session end messaging which cannot be available before the session actually ends - such as the fact that the decryption keys for the content have been destroyed or the exact position in the stream at which playback stopped. This information is used for the actual operation of the service (business rules, bookmarks etc.), not just for post hoc analytics.

We know there are scenarios where this message doesn't get sent, but these are a low enough fraction of sessions that we can deal with those discrepancies.

It would be great to have a way to send this message which did not block the browser UI.

It would also be great to be able to employ asynchronous methods in the construction of the message itself. For example using WebCrypto methods to encrypt or sign it. And it would be even better to have a chance to process the response (for example to remove state stored in local storage once the receipt of the information has been acknowledged).

One idea I had would be to have a special Web Worker that was allowed to continue executing for a short while after the visible page has gone. I'm not involved in browser implementation so I don't know how crazy that would be in terms of browser internals.

ůMark
Received on Friday, 15 February 2013 20:44:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 15 February 2013 20:44:57 GMT