Re: Resource timing buffer

While in onresourcetimingbufferfull, getEntries() was intended to be 
"stable", i.e. it should have "buffer size" (N) number of entries.  New 
RT entries occuring duringthe callback would go into a queue. Then, per 
option #1 in onresourcetimingbufferfull, if clearResourceTimings() is 
called, the first N entries are removed and N+1 queued entries onward 
take their place.

Without the onresourcetimingbufferfull text, I'd be worried that the 
developer could lose RT events. If they're interested enough to listen 
to onresourcetimingbufferfull, they probably want every single RT event, 
and the only way to work around the possibility of lost events during 
the callback is to just set a huge buffer instead and call it a day.

But it does complicate things and the description is kind of hard to 
follow. I can't think of any other web APIs that require this level of 
buffer managementto follow the lead from?

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

On 4/29/2013 9:18 PM, James Simonsen wrote:
> That implies that the buffer can change while 
> the onresourcetimingbufferfull callback is running. Is that expected? 
> That'd mean it's not safe to clearResourceTimings() after 
> getEntries(), because a new entry may have appeared in the meantime.
>
> In Blink, this would only be possible if a synchronous request took 
> place during the callback. I don't think that's something we should go 
> out of our way to support.
>
> James
>
>
> On Mon, Apr 29, 2013 at 6:10 PM, Nic Jansma <nic@nicj.net 
> <mailto:nic@nicj.net>> wrote:
>
>     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
>
>