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

On Sun, Dec 8, 2013 at 4:04 PM, Arvind Jain <arvind@google.com> wrote:
> 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.

Agreed.

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

The more I think about it, the more I think that having strict limits
in the spec won't help us that much. Given that we need to have
max-queued-per-origin limits, we still need a way to signal to the
page if it bumped into those limits or not.

That said, I think it would be good if we who are doing the initial
implementation of these specs could have an implementor-agreement on
what limits to use for now. And maybe even put such a limit as an
non-normative note in the spec, mostly as a documentation for web
developers.

So we still need to have a way to signal to the author if a request
was queued or not. The two ways I can think of are:

1. Have a way to query the status of old requests. I.e. you can see if
old requests success/fail and failure reason (size too large, network
problems, etc).
2. Synchronously return true/false at the time when the request is queued.

1 is more feature full, but more work to implement.

2 has the downside that implementing a synchronous true/false is more
work if you want to avoid synchronous communication between the
child-rendering-process and the parent-management-process.

One implementation strategy would be to asynchronously signal to all
child processes how much data is currently queued for a given origin.
Then the child can just compare against that whenever a new request is
queued. This does introduce a small race if two or more child
processes attempt to queue requests at the same time. However the only
harm is that slightly more than allowed data would be queued, which
isn't really a big deal.

There's no way to queue unlimited data anyway, at least not without
opening infinite number of child processes which I suspect would be a
bigger problem anyway if that was possible :)

So I think 2 gets my vote.

/ Jonas

Received on Tuesday, 10 December 2013 01:56:27 UTC