Re: [User Timing] Integration with Performance Timeline

On Wed, Jul 11, 2012 at 9:41 AM, Jatinder Mann <jmann@microsoft.com> wrote:

>  I disagree with the notion that we should only use the generalized API
> surface (e.g., getEntries, getEntriesByType, getEntriesByName) and not
> allow any specific methods to be defined for a particular metric. We should
> continue to evangelize the generalized APIs if we want web developers to
> focus on them, but that doesn’t mean we shouldn’t add specialized APIs.***
> *
>
> ** **
>
> As an example, Resource Timing already has its own set of APIs specific to
> its needs (e.g., clearResourceTimings, setResourceTimingBufferSize,
> onresourcetimingbufferfull).
>

These are all on the recording side. They're not getters. Likewise, I'm not
complaining about mark() and measure().


> ****
>
> User Timing is also fundamentally different from Resource Timing in that
> Resource Timing implicitly captures data (e.g.,  all resources are opted-in
> by default) whereas a developer explicitly needs to opt-in (e.g., use
> mark(), measure()) in order to use User Timing to capture data. The key
> benefit I see of getMarks/getMeasures is that it provides just the filtered
> User Timing data in JSON notation without the overhead of the objects in
> the order that the marks and measures were called. Considering a developer
> may only be interested in this information and considering users on metered
> networks, the option of sending just the right filtered data seems like a
> positive feature.
>
> ** **
>
> Also, performance.now() doesn’t replace getMarks and getMeasures.
> getMarks/getMeasures continue to provide a standardized and interoperable
> way to collect your filtered mark/measure data in JSON format.
>

getEntries() is our standardized way to get JSON format.

If people want another way of getting marks and measures in JSON, they can
write it in JavaScript. There's no need for developers to wait for another
spec to be implemented and shipped in every browser.

When we had made the changes to add the Performance Timeline overhead to
> each spec, we had at that time discussed and decided to leave these APIs
> in. The spec has been stable for quite some time, these APIs don’t break
> any WebIDL rules, they give value of providing specialized functionality,
> even with them in we can continue to evangelize the generalized API
> surface, why change it now?
>

This is an extremely weak argument. Just because it's there doesn't mean
it's good.

I'm not interested in adding fluff features. Everything we've done so far:
Navigation Timing, Resource Timing, Page Visibility, and Request Animation
Frame have extended the web platform in a way that web developers couldn't
have. User Timing is already of questionable value, since it can be
implemented in JavaScript. The only way it can add value to the platform is
to add entries to the Performance Timeline, which is otherwise immutable
from JavaScript.

James