- From: Jatinder Mann <jmann@microsoft.com>
- Date: Tue, 21 Aug 2012 22:31:49 +0000
- To: James Simonsen <simonjam@chromium.org>, "public-web-perf@w3.org" <public-web-perf@w3.org>
- Message-ID: <AE5FFD9402CD4F4785E812F2C9929D652277344C@SN2PRD0310MB383.namprd03.prod.outlook.>
Nice find James. Let's close on the right behavior in this week's conference call; I will add it to the agenda. From: 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
Received on Tuesday, 21 August 2012 22:32:29 UTC