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?