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

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

Received on Tuesday, 3 December 2013 18:37:23 UTC