- From: Chase Douglas <chase@newrelic.com>
- Date: Wed, 30 Oct 2013 16:04:19 -0700
- 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>
- Message-ID: <CAKNWE6GwR-HKHVLsoqYocvsaeqWfV7+-dYAO98-M=0kjct4EkA@mail.gmail.com>
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