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

On Tue, Dec 3, 2013 at 9:55 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> 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.
>

Hmm, I'm not sure I follow this. If I want fire-and-forget semantics, I'll
just fire an XHR without actually defining any callbacks, and that's that.
On the other hand, if my application needs an explicit ack to know that the
message was delivered, then I'll add a callback. If you *must* get a
callback, then use a sync XHR, but you'll also pay dearly for that...


> 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 think Yoav correctly pointed out that ability to batch and defer requests
can also be treated as a separate requirement.. which is also useful beyond
just beacon and can be grafted onto XHR.

http://lists.w3.org/Archives/Public/public-web-perf/2013Dec/0000.html


> 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 agree on fire-and-forget, but XHR already provides that, hence I'm not
sure what we win by defining new API? The problem with XHR is that there is
a race condition on onunload which cancels the requests -- if we address
that, then the problem is mostly solved.