Re: Resource timing buffer

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