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

Re: [Beacon] spec feedback + few suggestions

From: Ilya Grigorik <igrigorik@google.com>
Date: Wed, 30 Oct 2013 14:37:52 -0700
Message-ID: <CADXXVKqHF4XrbMV3RqoCAeafQB-8atR=3qKw1vZT9YsdLYFGqQ@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Chase Douglas <chase@newrelic.com>, Jatinder Mann <jmann@microsoft.com>, public-web-perf <public-web-perf@w3.org>
> The only way to enable that would be to use prompting "this page wants
> to run in the background", and that's clearly not something we want to
> force upon all Beacon users. I agree that background uploads is an
> interesting use case, but the security model is different enough that
> it's better handled separately.
>

Yep, this is exactly where ServiceWorker and Alarm are heading -- they'll
require some user opt-in, and with that in place you can then schedule
background syncs, uploads, etc.


> > I think it makes sense that browser implementations have limits. But
> > implementation-specific variability can change as needed over time. Specs
> > can't be changed as easily.
> >
> > Could we add a method for scripts to ask what the implementation limits
> are
> > (both size and frequency)? We're using query strings to send data in
> certain
> > places, and figuring out what will fit into query strings is annoying.
>
> If the limits aren't specified it means that authors won't be able to
> depend on what works and what doesn't work. Being able to depend on
> such things is the whole point of having an API. Asking authors to
> remember to check what the limits are of the specific browser/user
> seems bound to lead to bugs.
>

+1. As a developer, I want to have some well known operational parameters
for what to expect from different browsers, which is why it should be in
the spec.

ig
Received on Wednesday, 30 October 2013 21:39:05 UTC

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