Re: Notification for new navigation timing entries

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
>