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

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

From: Yoav Weiss <yoav@yoav.ws>
Date: Tue, 3 Dec 2013 13:52:01 +0100
Message-ID: <CACj=BEjuVuyDHXDCR4BGuxEO2j1mYcA_r1gF8-Dtus0EJDC8QQ@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Doug Turner <doug.turner@gmail.com>, Arvind Jain <arvind@google.com>, Ilya Grigorik <igrigorik@google.com>, Jatinder Mann <jmann@microsoft.com>, John Mellor <johnme@google.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>
On Tue, Dec 3, 2013 at 5:12 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Mon, Dec 2, 2013 at 7:43 PM, Doug Turner <doug.turner@gmail.com> wrote:
> > Having this be a synchronous API is going to be troublesome to implement.
> > Please consider doing asynchronous.
>
> I agree that it makes the API significantly harder to implement.
> Simply returning a Promise does not work though as a beacon created
> during onunload (which is one of the main use cases) will return a
> promise that won't get resolved until the user leaves the page.
>
> So I think that leaves us with
> * Put in place strict limits as to make returning a result less important.
> * Add an API which exposes pass/fail results of old requests from
> previous page loads.
> * Deal with the implementation complexities of sync results.
> * Allow the page to query UA-limits prior to creating the beacon.
>
> The last option is somewhat hard given that simply having a
> per-request limit is fairly useless. Any implementation will want to
> have some form of max-queued-size limit as well.
>
> / Jonas
>

Can't size limits (both per-request and for max-queued-size) be enforced
synchronously (and fail immediately if the limit is reached), while the end
results of the beacon are returned asynchronously, if the tab is still
alive?
Would that complicate implementation?
Received on Tuesday, 3 December 2013 12:52:31 UTC

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