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

Re: [beacon] no limits, no retry, no batching, post only

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 3 Dec 2013 09:55:38 -0800
Message-ID: <CA+c2ei90eknKkcFUBr+EAjfc-8pcxyh_HjG6ktfPnOk+H0FGOw@mail.gmail.com>
To: Ilya Grigorik <igrigorik@google.com>
Cc: Jatinder Mann <jmann@microsoft.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>
On Tue, Dec 3, 2013 at 9:46 AM, Ilya Grigorik <igrigorik@google.com> wrote:
>> > In theory, this could provide following semantics:
>> > - marking request as "detach" forces it to be async (i.e. can't do sync
>> > XHR
>> > with detach=true)
>> > - detach is functionally equivalent to XHR, callbacks and all.
>> I explicitly do not want to provide any callbacks. That will limit the
>> UAs ability to be smart about when the beacon is sent. I.e. the more
>> information about when a beacon is sent that we expose, the larger the
>> risk that pages will break as implementations change when the beacon
>> is sent in order to save battery.
> So, my proposal is to simply ignore any/all callbacks *if* the parent page
> is gone:

My point is that I don't want to fire normal XHR-like callbacks while
the page is still running. That will increase the risk that pages come
to depend on a particular timing of the network request happening.

As an implementor, I want to be able to delay the network request by 5
minutes in order to save battery and/or in order to prioritize the
bandwidth for more urgent requests. I'm worried that if I don't
implement the perfect strategy when shipping the initial
implementation, that changing strategy later can break existing
content that has come to depend on the shipping implementation.

I.e. I think there are benefits to having a fire-and-forget API. Such
an API would be different enough from XHR that reusing the XHR API
will cause more confusion than it will help.

I also don't think that the current sendBeacon API is going to be
particularly hard for developers to understand.

/ Jonas
Received on Tuesday, 3 December 2013 17:56:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:37 UTC