Re: Resource timing buffer

I'm not sure if I understand your changes.

Does it matter whether we call onresourcetimingbufferfull() right before we
are trying to insert the max+1'th item or right after we inserted the
max'th item?

Here is what I was planning to change:

Section 4.4:
onresourcetimingbufferfull attribute

The callback onresourcetimingbufferfull is triggered when the buffer used
to store the list of
PerformanceResourceTiming<http://www.w3c-test.org/webperf/specs/ResourceTiming/#performanceresourcetiming>
is
full. The callback can be used to package existing
PerformanceResourceTiming<http://www.w3c-test.org/webperf/specs/ResourceTiming/#performanceresourcetiming>
resources
and clear the buffered
PerformanceResourceTiming<http://www.w3c-test.org/webperf/specs/ResourceTiming/#performanceresourcetiming>
 list. <END>

(Remove all text after this in this section).

Section 5.1 step 3.20 and 3.21 are now:


   1. If the *primary buffer* is full, and the callback
   onresourcetimingbufferfull <#dom-performance-onresourcetimingbufferfull> is
   defined, the callback
onresourcetimingbufferfull<#dom-performance-onresourcetimingbufferfull>
must
   be triggered.
      1. If the clearResourceTimings
<#dom-performance-clearresourcetimings> method
      is called in the
onresourcetimingbufferfull<#dom-performance-onresourcetimingbufferfull>
callback,
      clear all PerformanceResourceTiming <#performanceresourcetiming> objects
      in the*primary buffer*.
      2. If the
setResourceTimingBufferSize<#dom-performance-setresourcetimingbuffersize>
method
      is called in the
onresourcetimingbufferfull<#dom-performance-onresourcetimingbufferfull>
callback,
      set the maximum size of the *primary buffer* to the maxSize parameter.
   2. If the *primary buffer* is not full, add the
PerformanceResourceTiming<#performanceresourcetiming> object,
   created in step 3.1 <#step-create-object>, to the *primary buffer*.
*Otherwise,
   discard it.*




On Tue, Apr 30, 2013 at 8:48 AM, Deng, Pan <pan.deng@intel.com> wrote:

>  If no vendor implemented that, I would suggest not keeping that
> statement. Developers may be given a lot of uncertain imagination if we
> keep it there. For example:****
>
> **1)      **Consider the case the onresourcetimingbufferfull triggered
> but the clear method is never invoked, shall we keep the incoming entries
> during callback, and drop entries after callback? it is weird and developer
> won’t get a stable result. Keep all the entries as we regard they
> interested in every entry? then why we keep   “setResourceTimingBufferSize”
> method, the “N” become a read control rather than a buffer control.****
>
> **2)      **Even clear method is invoked during callback, what if the
> temporary buffer is beyond the buffer size at the meantime? (Processing
> model 3.20.4 said copy all the temporary when clear), will 2nd“onresourcetimingbufferfull” event be fired and lead to nested callback?
> ****
>
> **3)      **Consider my call back looks like {step A..; step
> B:getEntriesByType(); step C…}, if a new entry comes during step A, will
> the getEntriesByType() return “N+1” entries.****
>
> ** **
>
> To simplify the spec and regard Nic’s concern, I suggest a replacement
> like: PerformanceResourceTiming<http://www.w3.org/TR/resource-timing/#performanceresourcetiming>
> *of the resource that fetched during the callback will be held and a
> storing trial to *PerformanceEntryList<http://www.w3.org/TR/performance-timeline/#performanceentrylist>
> * after the callback.***
>
> And the processing model can be changed like: ****
>
> 3.20: if the pri*mary buffer* is full, drop PerformanceResourceTiming<http://www.w3.org/TR/resource-timing/#performanceresourcetiming>object and terminate. Otherwise, store the
> PerformanceResourceTiming<http://www.w3.org/TR/resource-timing/#performanceresourcetiming>object.
> ****
>
> 3.21: check if the primary buffer is full or not, if full,
> onresourcetimingbufferfull<http://www.w3.org/TR/resource-timing/#dom-performance-onresourcetimingbufferfull>must be trigged.
> ****
>
> ** **
>
> In this case, developers do have chance to clear buffer in suggested
> 3.21(once buffer achieves N, not N+1), then drop of next entry(in suggested
> 3.20) can be avoid. J****
>
> ** **
>
> Thanks****
>
> Pan****
>
> ** **
>
> *From:* Nic Jansma [mailto:nic@nicj.net]
> *Sent:* Tuesday, April 30, 2013 9:38 AM
> *To:* James Simonsen
> *Cc:* Arvind Jain; public-web-perf
> *Subject:* Re: Resource timing buffer****
>
> ** **
>
> 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?
>
> ****
>
> - Nic****
>
> http://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.
>
> ****
>
> - Nic****
>
> http://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****
>
> ** **
>
> ** **
>
> ** **
>