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

> 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?

Though, PerformanceHighResTiming implies it is the high res version of PerformanceTiming, in light of the fact that we later added more descriptive interface names like PerformaceResourceTiming, PerformanceMarks, PerformanceMeasures, the suggested name would now seem a bit ambiguous (e.g., why is this called just timing and the others more descriptive?). I think to be more consistent with other PerformanceTimeline entries, we should stick with a more descriptive name like PerformanceNavigationTiming.

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

I think that is fair feedback; we should have send out a separate mail announcing Navigation Timing 2 and its purpose.

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

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

I don't think it is a question of whether the PerformanceTiming interface of the Navigation Timing spec works doesn't work properly in real life; the PerformanceTiming interface delivers the data it set about to make available, we have just found a better model of exposing that type of data and with slightly better resolution. Three user agents have interoperably implemented the PerformanceTiming interface and sites have taken dependencies on it. Considering those dependencies, user agents that have implemented this interface will not want to break those sites by removing this interface. For that reason, I think we need to complete the work to document this interface in the Navigation Timing specification. 

I agree that Navigation Timing 2, which adheres to the model presented in Performance Timeline, is what we want to evangelize to developers in the future. I think Navigation Timing 2 spec should make the Navigation Timing interfaces (PerformanceTiming and PerformanceNavigation) optional. This way Opera can decide whether to implement just Navigation Timing 2 or both specs.

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

Per your feedback, the working group decided to publish Performance Timeline back to Last Call, http://lists.w3.org/Archives/Public/public-web-perf/2012May/0021.html.


Thanks,
Jatinder

Received on Tuesday, 15 May 2012 17:20:31 UTC