RE: [Resource Timing] Contradiction in onresourcetimingbufferfull behavior

I prefer not truncating within setResourceTimingBufferSize().
I feel "truncate" behavior cannot be inferred from method name "setResourceTimingBufferSize",
another reason is, which items should be purged? How to define "older"? by startTime? responseEnd? Or the order they occur in page?

My opinions are:
1)      'clearResurceTimings()' ought to be the only method within which the resource entries purged.
2)      'setResourceTimingBufferSize()' adjust buffer capacity, nothing else happen even user set a number that less than current size.
3)      Onresourcetimingbufferfull triggered once user agent attempt to push a new item to a full buffer(current size >= buffer capacity). We should allow user to decide truncate or adjust buffer capacity in callback function, if there are space after callback, new item should be saved in buffer, and otherwise it should be dropped.

In addition, can we expose a method to return buffer capacity? user can easily use it to decide "future" bufferSize.

Thanks

Pan

From: Karen Anderson (IE) [mailto:Karen.Anderson@microsoft.com]
Sent: Friday, July 20, 2012 2:28 AM
To: James Simonsen; public-web-perf
Subject: 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<http://www.w3.org/TR/resource-timing/#performanceresourcetiming> will continue to be collected beyond the maximum limit of the resources allowed in the PerformanceResourceTiming<http://www.w3.org/TR/resource-timing/#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.

-Karen

From: simonjam@google.com<mailto:simonjam@google.com> [mailto:simonjam@google.com] 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.

James

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.

[1] http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#dom-performance-setresourcetimingbuffersize

[2] http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#dom-performance-onresourcetimingbufferfull