Re: Resource timing buffer

I believe the idea was to give the developer the opportunity to smartly 
manager their RT buffer instead of just setting it at 10,000(and consume 
resources) so they didn't have to worry about it.

For example, a developer could leave the default 150 buffer size and:
1) Listen to onresourcetimingbufferfull
2) When onresourcetimingbufferfull is triggered:
2a) getEntriesByType(...) andanalyze/process/submit/store these 100 
resources if they wanted
2b) clearResourceTimings()
3) In the meantime, the browser has been caching any new entries and 
takes the action defined inonresourcetimingbufferfull 
(http://www.w3.org/TR/resource-timing/#dom-performance-onresourcetimingbufferfull) 
after the callback has completed.
4) The developer can now analyze any new events that came in during step 
#2 or wait for the next onresourcetimingbufferfull

Otherwise, if any new RT events come in after #1, and the browser stops 
recording them, the developer has no way of knowing they occurred and 
cannot retrieve them.

- Nic
http://nicj.net/
@nicj

On 4/29/2013 7:32 PM, Arvind Jain wrote:
> http://www.w3c-test.org/webperf/specs/ResourceTiming/
>
> Re. this comment:
> onresourcetimingbufferfull attribute
> ....*While executing the onresourcetimingbufferfull callback, 
> PerformanceResourceTiming will continue to be collected beyond the 
> maximum limit of the resources allowed*....
>
> I tried to look up why we added it and couldn't find anything. 
> Currently this logic is not implemented by IE and Chrome.
>
> Should we remove this? i.e. once the limit is reached, don't store new 
> resource timing objects irrespective of whether you are executing this 
> callback or not.
>
> Arvind