Re: Resource timing buffer

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
>>>
>>>
>>>
>>
>>
>