RE: [Beacon] Beacon API Specification

On Wed, Mar 13, 2013 at 1:14 AM, Ilya Grigorik <igrigorik@google.com> wrote:
> Beacon could help solve a lot of problems in this space: by moving analytics and other beacon-like
> requests to this new API we can let the browser become a lot smarter about when the requests
> are actually sent. E.g., batch multiple beacons and dispatch them next time the user initiates an
> interactive request, etc.

I’ve updated the introduction to include this example.

On Wed, Mar 13, 2013 at 1:14 AM, Ilya Grigorik <igrigorik@google.com> wrote:
> I don't think there is any good reason to limit BeaconHTTPMethod to POST and PUT? Google Analytics
> and many other analytics vendors all use "pixel GETs" to beacon the data, and we should provide a
> low friction way to leverage "beacon" with existing solutions.

I’ve added support for the GET HTTP method as well.

The latest spec draft can be found here: https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/Beacon/Overview.html.


Thanks,
Jatinder

From: Reitbauer, Alois [mailto:Alois.Reitbauer@compuware.com]
Sent: Wednesday, March 13, 2013 12:41 AM
To: Ilya Grigorik; Jatinder Mann
Cc: public-web-perf@w3.org
Subject: Re: [Beacon] Beacon API Specification

Good points Ilya.

The onunload use case is there as it is the biggest problem today and we wanted to start with a concrete example. This part can be made more general however. We might need to rephrase this. Netflix also had another use case they were looking into.

Our initial goal was to solve a very specific problem and come up with an initial spec. That this approach is applicable to other use case as well is great. I fully agree with your mobile scenario. It, however, should not make the spec any more complex like dealing with response data etc.

Extending the spec to also support GET should not be a really issue, especially if this helps to keep compatibility with current server-side implementations.

The distinction between XHR and Beacon is also about complexity. The processing model of XHR is very complex. Beacon would not make it simpler, although the functionality is very simple. Jatinder looked into this in more detail.

// Alois


From: Ilya Grigorik <igrigorik@google.com<mailto:igrigorik@google.com>>
Date: Wednesday, March 13, 2013 1:14 AM
To: Jatinder Mann <jmann@microsoft.com<mailto:jmann@microsoft.com>>
Cc: "public-web-perf@w3.org<mailto:public-web-perf@w3.org>" <public-web-perf@w3.org<mailto:public-web-perf@w3.org>>, Alois Reitbauer <alois.reitbauer@compuware.com<mailto:alois.reitbauer@compuware.com>>
Subject: [Dynatrace.com]Re: [Beacon] Beacon API Specification
Resent-From: "public-web-perf@w3.org<mailto:public-web-perf@w3.org>" <public-web-perf@w3.org<mailto:public-web-perf@w3.org>>
Resent-Date: Wednesday, March 13, 2013 1:16 AM

On Wed, Mar 6, 2013 at 8:43 AM, Jatinder Mann <jmann@microsoft.com<mailto:jmann@microsoft.com>> wrote:
A few weeks earlier, Alois and I had reached out to other working groups describing the poor performance patterns used to send data during the beforeunload and unload handlers. To avoid overloading existing methods, which may cause confusion and hurt adoption for our use case, we had agreed on sharing a more concrete Beacon API proposal [1].

We have put together a proposal for the Beacon API in this specification: https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/Beacon/Overview.html. Please review this specification and provide feedback.

Initially, we were considering whether to create a XHR variant or a separate Beacon API. However, considering some of our requirements differ significantly from the existing XHR, it appears that having a completely separate Beacon concept from XHR may be less confusing for developers.

Short of not returning any callback, what are the other differences?

One of the goals of this API is that developers use it as a reliable means of transmitting data without needing confirmation whether the data has successful been sent, as the user agent now takes that responsibility. However, this version of the proposal does not attempt to make a guarantee that the data will be sent, just a best effort. For example, we don’t plan on attempting to send the data again if it failed the first time or plan on persisting the data locally to send later if the browser has been shut down. If there is a demand for those scenarios, we can consider them further.
+1.

On a quick pass over the current draft, a few thoughts:

There is big focus on the unload case, but while that is an important use case, I actually wouldn't consider it as the most interesting one. The most important bit is actually hidden at the very end of current description: "This method can be used at any time to asynchronously transfer data to a web server, without the need to check whether the data transfer has succeeded or not."

We all know that mobile web is exploding.. And optimizing battery life is a huge deal for mobile. Beacon could help solve a lot of problems in this space: by moving analytics and other beacon-like requests to this new API we can let the browser become a lot smarter about when the requests are actually sent. E.g., batch multiple beacons and dispatch them next time the user initiates an interactive request, etc.

I would lead the description with that last sentence, and then provide a few use cases. Unload is a good one, but right now it reads as if its the only one, which is not the case...

---

On Beacon vs. XHR: I'm sympathetic to offering a clear distinction between the two, but I wonder if we would just end up reimplementing the same thing twice. For example, I don't think there is any good reason to limit BeaconHTTPMethod to POST and PUT? Google Analytics and many other analytics vendors all use "pixel GETs" to beacon the data, and we should provide a low friction way to leverage "beacon" with existing solutions.

ig
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Compuware Austria GmbH (registration number FN 91482h) is a company registered in Vienna whose registered office is at 1120 Wien, Austria, Am Euro Platz 2 / Gebäude G.