RE: [User Timing] Integration with Performance Timeline

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

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.

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?

Thanks,
Jatinder