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

Summarizing this thread..
There is agreement to access Navigation Timing via PerformanceTimeline
using a PerformanceNavigationTiming object. The contention is around:
1) Should PerformanceTiming be removed from current NavigationTiming
specification given we have a better new way?
2) If PerformanceTiming is kept, should the new PerformanceNavigationTiming
interface be included in current NavigationTiming specification or should
we do a v2?
As Jatinder mentioned, the consensus so far was to do v2, and retain both
old and new style of accessing navigation timings.

We should discuss this in tomorrow's call. It'd also be good to other folks
to chime in here or on the call tomorrow.

Arvind

On Tue, May 15, 2012 at 10:18 AM, Jatinder Mann <jmann@microsoft.com> wrote:

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