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

OK I updated the definition to have a boolean return value.
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/Beacon/Overview.html

The updates are in Section 4.2 and Step 7 and 9 of the Processing Model
(Section 4.3).

Please let me know if there are more comments. I think I've addressed all
comments raised so far.

Arvind


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

> On Mon, Dec 9, 2013 at 10:46 PM, Arvind Jain <arvind@google.com> wrote:
> >
> > Is it preferable to keep the return value void but throw a quota exceeded
> > exception if the queue limit would be exceeded or change the return
> value to
> > a boolean?
>
> No. Throwing exceptions in intermittent conditions is a bad idea. It
> can cause hard-to-reproduce bugs where important functionality
> implemented in code that's run after the throwing function call
> sometimes breaks with little help for the author to figure out why.
>
> Keep in mind that the exception might never happen on the developer's
> computer, but only on the end user's computer. At worst, there might
> even be an exception handler higher up in the callstack which prevents
> the exception from getting logged through window.onerror.
>
> So returning true/false is a safer syntax.
>
> / Jonas
>
> >
> >
> > On Mon, Dec 9, 2013 at 5:55 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> >>
> >> 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
> >
> >
>