RE: [Resource Timing] Contradiction in onresourcetimingbufferfull behavior

It seems like the intention of the first statement was to ensure no data loss.  However, I also agree that if the user does call setResourceTimingBufferSize() with a smaller capacity that we should honor it.  We have to assume they have their reasons.  If we do honor truncating, I would suggest that we purge older items first.  On another note, I am not sure why this would only apply after the clearResoureceTimings method is called.  It certainly becomes awkward in the scenario where the buffer is full, then within the onresourcetimingbufferfull callback the user calls setResoureceTimingBufferSize() to less than the current capacity.  Onresourecetimingbufferfull indicates that while executing the callback "PerformanceResourceTiming<> will continue to be collected beyond the maximum limit of the resources allowed in the PerformanceResourceTiming<> interface".  Let's say that the original buffer size is 100, the user wants to truncate to 75 and during the onresourecetimingbufferfull callback 10 more resources are collected.  Do we purge the oldest 35 entries so that we can keep the newest 10 and still be at size 75?  Or do we purge 25 and keep the 10 in the temporary buffer until the primary buffer can accommodate them?

I agree that these types of scenarios need to be flushed out more.


From: [] On Behalf Of James Simonsen
Sent: Wednesday, July 11, 2012 5:10 PM
To: public-web-perf
Subject: [Resource Timing] Contradiction in onresourcetimingbufferfull behavior

It's not clear what to do when setResourceTimingBufferSize() is called with a smaller value during the onresourcetimingbufferfull callback.

The third paragraph under setResourceTimingBufferSize() [1] says:

"if the maxSize parameter is less than the number of elements currently stored in the buffer, no elements in the buffer are to be removed."

The second bullet under onresourcetimingbufferfull [2] says:

"setResourceTimingBufferSize is called - The PerformanceEntryList will extend and / or truncate to the buffer size specified."

So the first says to truncate and the second says not to. The processing model doesn't mention truncation.

I don't have a strong preference which way we go. It seems like an odd thing for a user to do, but if they willfully make it smaller in response to the callback, it seems we ought to honor that and truncate the items.

OTOH, it's simpler to just ignore it. If we decide to truncate, we have to define that too.


P.S. The first line I quoted should be capitalized in the spec.

P.P.S. The second quote infers it's possible to extend _and_ truncate. That seems pretty weird.



Received on Thursday, 19 July 2012 18:31:45 UTC