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

I'm continuing to make changes to the current document. I think we should
finalize the behavior and then we can debate whether to retrofit to XHR.

I fixed the processing model in the latest update to make it clear the most
steps in the call are synchronous and the only one that's not is the
network part (once all checks have been performed and the browser decides
to queue the call to be sent over the network). E.g. the size check happens
synchronously.

https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/Beacon/Overview.html

We still need to nail down the size/queue limits. There is no mention of
queue limits in the document yet.


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

> On Tue, Dec 3, 2013 at 10:22 AM, Ilya Grigorik <igrigorik@google.com>
> wrote:
> > 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.
>
> I meant "I" as in "I as an implementor".
>
> >> 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
>
> As an implementor, think the ability to have a request outlive the
> page lifetime goes hand-in-hand with the ability for the
> implementation to defer the request. If I can't abort the request as
> soon as the user navigates elsewhere I want to be much more flexible
> with when I start the request.
>
> But sure, if you want to add these two things as orthogonal features
> on top of XHR then I'll look forward to such a proposal. But I'd need
> see proposals for both features before I can evaluate them.
>
> / Jonas
>
>