Re: [Beacon] Beacon API Specification

On Wed, Mar 6, 2013 at 8:43 AM, Jatinder Mann <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