Re: [minutes] 2012-04-25 Web Performance WG Teleconference #70

On Wed, 02 May 2012 00:50:38 +0200, Jatinder Mann <jmann@microsoft.com>
wrote:

> Yes. We designed the getEntries, getEntriesByType and getEntriesByName  
> methods to be a single API that can be used to retrieve any performance  
> metric. Though PerformanceResourceTiming of the Resource Timing spec and  
> PerformanceMarks and PerformanceMeasures of the User Timing spec objects  
> can be retrieved from those methods, PerformanceTiming cannot.  
> PerformanceTiming is exposed on performance.timing rather than be  
> returned as an object.
>
> To ensure that PerformanceTiming data can be obtained using those  
> retrieval methods, we are proposing a PerformanceNavigationTiming object  
> that would be returned when using those methods. It would returns the  
> same data that PerformanceTiming interface would, except in  
> sub-millisecond resolution.

All sounds fair and good, I fully agree that having consistent APIs is for
the better. The names are still confusing me though, as it seems
PerformanceNavigationTiming is not the timing data for
PerformanceNavigation. Maybe a better name would be
PerformanceHighResTiming, or some such?

>> Now, because of historical reasons and compatibility issues, the  
>> PerformanceNavigationTiming
>> interface is being removed from the current set of specs, and pushed to  
>> the future. (Appearantly
>> we have planned a new, future spec, Navigation Timing 2.)
>
> The PerformanceNavigationTiming interface was never proposed in the  
> current set of specs; it was first proposed in Navigation Timing 2.

Considering that the first mention I can find of Navigation Timing 2 was
at the same time this change was mentioned, I consider the specs to be
equal at that time. ;) Note that I still haven't seen a rationale for
Navigation Timing 2 on this list, that might be what is contributing to
the confusion. It would presumably be good to send a separate mail about
the new spec.

>> If we for a second ignore the compatibility issues, wouldn't the proper  
>> way to fix this be by writing
>> the specs the way they ought to be, as none of them are final yet? And  
>> if we do care about compatibility,
>> will we not get even bigger compat problems if we ship a spec now which  
>> we know will be incompatible
>> with version 2? If we have a solution for fixing such issues for  
>> version 2, why don't we just use that solution now?
>
> The Working Group chatted about this option in our last call. The key  
> difference here is that PerformanceTiming data is not incompatible with  
> PerformanceNavigationTiming; the data is just retrieved differently. One  
> lives on performance.timing, whereas the other is obtained using the  
> getEntries* methods. Additionally, the PerformanceTiming data is in  
> milliseconds, whereas PerformanceNavigationTiming is in sub-millisecond,  
> the data can still be compared against each other.
>
> As PerformanceNavigationTiming is returned as an object, adding it will  
> not pollute the performance namespace any further.
>
> Considering PerformanceTiming has been shipped

I thought PerformanceTiming was part of Navigation Timing, which is still
in CR? The purpose of a CR being to ensure it works properly in real life.
If we have discovered that we would rather change it, this would be the
time to do so, rather then in 2.0.

> and is being used by real developers and that the new interface doesn't  
> significantly change the data, the Working Group felt that this was best  
> to standardize Navigation Timing and make the new changes in the next  
> version of the spec.

Developers should be aware that they are working with an unpublished
specification, and they might have to update their implementations.

> One immediate benefit is that developers can rely on the implementations  
> of PerformanceTiming to be interoperable.

I don't see this benefit. Whether we use PerformanceTiming or
PerformanceNavigationTiming in the final Navigation Timing spec, compliant
user agents will still be interoperable. User agents which only
implemented drafts of the spec cannot be trusted to be fully interoperable
with the final in any case.

On the other hand, I see this as making user agents non-interoperable,
unless they develop and support deprecated features. New user agents
implementing this would have to implement the then-deprecated
PerformanceTiming in order to be interoperable, and user agents which  
already have support will need to continue supporting it. Tutorials and  
examples will forever after be confusing. One of the problems we want to  
avoid, having redundant (and thus confusing) APIs will instead end up  
being with us indefinitely.

Given the current status, I think I agree with James Simonsen[1], we  
should encourage using PerformanceTimeline throughout, making sure this  
API works consistently. That includes keeping support for navigation  
entries in the Performance Timeline, and ironing out the kinks in  
Navigation Timing.

>> Regarding moving specs to CR, I believe (as a general principle) that  
>> one should not move to CR immediately
>> following a major edit (such as deleting an entire section), as issues  
>> such as the above might appear, and we
>> should allow ourselves time to discuss such issues.
>
> We don't expect the spec to move to CR until at least next week, which  
> would be two weeks after the changes were made. Would you like us to  
> move CR out another two weeks?

I think any CR should be delayed until two weeks after we all agree that
we should move to CR, to ensure everybody gets a chance to participate in
the discussion.

[1] http://lists.w3.org/Archives/Public/public-web-perf/2012Apr/0035.html

-- 
Sigbjørn Vik
Core Quality Services
Opera Software

Received on Friday, 11 May 2012 15:02:21 UTC