- From: Arvind Jain <arvind@google.com>
- Date: Tue, 30 Apr 2013 15:03:46 -0700
- To: James Simonsen <simonjam@google.com>
- Cc: Nic Jansma <nic@nicj.net>, public-web-perf <public-web-perf@w3.org>
- Message-ID: <CAOYaDdPnHcFBxHqW48DJocBWELNTAdp+Sj1t0zvzd26vt21wiA@mail.gmail.com>
I've updated the draft to reflect Pan's comments (call the onresourcetimingbufferfull callback on Nth instead of N+1th entry), and drop the logic for storing entries beyond N while executing the callback (given nobody seems to have implemented that logic). Please take a look at section 4.4 and 5.3.20 and let us know if there are any concerns. We can discuss this in tomorrow's telecon. Arvind On Tue, Apr 30, 2013 at 10:21 AM, James Simonsen <simonjam@google.com>wrote: > I wonder if we have to say this at all. The web is single threaded. I > believe most of the specs assume that. It's up to the browsers to maintain > that illusion and this could just be part of it. > > James > > > On Mon, Apr 29, 2013 at 6:38 PM, Nic Jansma <nic@nicj.net> wrote: > >> While in onresourcetimingbufferfull, getEntries() was intended to be >> "stable", i.e. it should have "buffer size" (N) number of entries. New >> RT entries occuring during the 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 management to follow the lead from? >> >> - Nichttp://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> 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(...) and analyze/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 in onresourcetimingbufferfull ( >>> 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. >>> >>> - Nichttp://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 >>> >>> >>> >> >> >
Received on Tuesday, 30 April 2013 22:04:18 UTC