Re: Notification for new navigation timing entries

+1 to all of the above.

Another minor requirement: ability to unsubscribe --
window.performance.observe returns an object that you can call
.disconnect() on, or some such? Note that MutationObservers solve this via
a slightly different pattern:

----
var observer = new PerformanceObserver(function(events) {
 events.forEach(function(event) {
   // ....
 })
});
observer.observe(window.performance, options); // subscribe
observer.disconnect(); // unsubscribe
----

The reason I suggested window.performance.observe() is because that's the
only object (I think) we would ever call observe on?

Re, #2: FF, IE folks, any feedback here?
Re, #3: I think we should treat buffers and observers as separate things.
Observers should get notifications regardless of the state of the buffer.
Assuming we have the observer model in place, the buffer's primary use case
becomes about providing event data for the initial load -- aka, events that
were emitted prior to you registering the observer (which is always delayed
during initial load).

ig


On Mon, Dec 8, 2014 at 12:30 PM, Nat Duca <nduca@google.com> wrote:

> The .observe approach seems to be a good direction for us to pursue. As I
> think through the use cases in more details, it becomes clear that there
> are two core requirements on a good event api:
> 1) it should support multiple consumers, such that different components on
> the page can both monitor the timeline independently
> 2) it should allow the conversion of the raw event data into javascript
> objects to be deferred as long as possible so performance intrusiveness is
> minimized
> 3) there should be a way to control which events are buffering vs not
> buffering, to control monitoring overhead. Ideally, this too is
> component-friendly rather than global.
>
> Currently, the global buffer fails on #1 and #3 but does succeed on #2. #1
> because there's a global buffer and #3 because the only way to turn off
> "buffering" is to set the buffer size to zero, which is a global operation.
>
> Thus, if I blur my eyes enough, I think what we're talking about here is
> introduce a layer *between* the global timeline and the event stream so
> that individual libraries can skip the timeline and instead buffer
> themselves through observers. That sounds really promising.
>
> So, as I look at window.performance.observe(..., callback) it starts
> sounding very promising.
>
> But, lets make sure we evaluate against the goals above. Namely:
> #1, multiple consumers: looks good
> #2, delayed conversion into js objects: are we sure that these performance
> arrays can be converted lazily? I think someone should go check with an
> implementer to be doubly/triply sure. People should be able to buffer up
> the event arrays for mostly-free without as long as they don't access the
> array items.
> #3, control over what records: if we began with
> window.performance.observe, we'd probably be in a good state: data isn't
> recorded without an observer. But, we need a transition plan to that: how
> does buffering work when the global timeline is full (or zero) AND you have
> an observer?
>
> On Mon, Dec 8, 2014 at 10:22 AM, Ilya Grigorik <igrigorik@google.com>
> wrote:
>
>>
>> On Mon, Dec 8, 2014 at 10:05 AM, Eli Perelman <eperelman@mozilla.com>
>> wrote:
>>
>>> I actually prefer the control you outlined with the MutationObserver
>>> proposal. Again, I believe the callback should receive a single event with
>>> an array of entries instead of the inconsistent array of events with a
>>> single entry.
>>
>>
>> The consistency part is debatable since MutationObserver API returns an
>> array of events [1]. And given that's the case, I'd argue we should do the
>> same? It's not clear to me that there are any benefits to adding another
>> layer of indirection?
>>
>> [1] http://www.w3.org/TR/dom/#concept-mo-queue
>>
>
>