> 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