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

Re: [Beacon] spec feedback + few suggestions

From: Chase Douglas <chase@newrelic.com>
Date: Wed, 30 Oct 2013 16:04:19 -0700
Message-ID: <CAKNWE6GwR-HKHVLsoqYocvsaeqWfV7+-dYAO98-M=0kjct4EkA@mail.gmail.com>
To: Jatinder Mann <jmann@microsoft.com>
Cc: Ilya Grigorik <igrigorik@google.com>, public-web-perf <public-web-perf@w3.org>, Jonas Sicking <jonas@sicking.cc>
On Wed, Oct 30, 2013 at 3:50 PM, Jatinder Mann <jmann@microsoft.com> wrote:

>  On Oct 30, 2013 2:31 PM, Ilya Grigorik wrote:****
>
> On Oct 30, 2013 2:31 PM, Ilya Grigorik wrote:
>
> > Right, exactly what we're trying to guard against.. Don't have a number
> yet, but I've reached out to the Google
> > Analytics team to see if they can provide some stats on what they see
> for their pings.****
>
> ** **
>
> It would be great if we can base our limit on data.
>

I still am concerned with setting too low of a limit. Analytics is a field
that is growing very rapidly. The amount of analytics that people are going
to want to send through something like this beacon API is going to increase
over time. Bandwidth is going to increase over time. Power usage is going
to decrease over time. Basing the amount on what people are doing today is
short-sighted.

What are you proposing should happen when 10 years from now we are unhappy
with the beacon spec because we can't send data that will feel like a tiny
tiny amount. For an example of a reasonable wording of limitations, look at
the web storage spec, which contains wording like:

"User agents may impose implementation-specific limits on otherwise
unconstrained inputs, e.g. to prevent denial of service attacks, to guard
against running out of memory, or to work around platform-specific
limitations."

"User agents should limit the total amount of space allowed for storage
areas."

"A mostly arbitrary limit of five megabytes per origin is recommended.
Implementation feedback is welcome and will be used to update this
suggestion in the future."

I think this sort of language would go a long way to ensure that there's a
reasonable recommendation of sizing without a hard limit that isn't
future-proof.
Received on Wednesday, 30 October 2013 23:04:51 UTC

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