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

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