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

Thanks for the clarifications. Let's see if I get this right:

The PerformanceTiming interface in the Navigation Timing Spec is
inconsistent with the PerformanceResourceTiming Interface in the Resource
Timing spec. To fix this, a new interface, the PerformanceNavigationTiming  
interface, was suggested. (To replace or complement the PerformanceTiming  
interface?)

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

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?

I am sure there is something I didn't get, so my apologies in advance.  
I'll be the first to admit that I have not been paying very detailed  
attention to the latest developments, but a call for going to CR is also a  
call to check the specs again. 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.

I would join the next conference call, but my first opportunity to do so  
would be on the 16th of May.

On Fri, 27 Apr 2012 19:59:22 +0200, Jatinder Mann <jmann@microsoft.com>
wrote:

>> This leaves me with a few questions. What is/was section 4.4 of the  
>> Performance Timeline?
>> What are the additions that Jatinder suggested? What is the rationale  
>> behind this move? It seems
>> we have enough micro-specs already, we don't need any more, and I am  
>> not sure I see how this
>> improves the specs.
>
> The Performance Timeline spec describes the interfaces to retrieve  
> performance metric data and the object that all performance metrics  
> extend. Resource Timing and User Timing specs require that data be  
> retrieved and stored using the Performance Timeline API.
>
> Not only was the Navigation Timing spec (PerformanceTiming interface)  
> written long before the Performance Timeline, as it had been shipped  
> unprefixed in multiple browsers, we have found that developers have  
> taken dependencies on it. We did not want to alter the PerformanceTiming  
> interface for compatibility reasons, and instead decided to add a  
> section in Performance Timeline spec (Section 4.4) to describe how the  
> navigation data would work in the Performance Timeline.  For example, if  
> you call performance.getEntries("navigation"), it would return a basic  
> PerformanceEntry object with only four attributes: name="document",  
> entryType="navigation", startTime=0, duration=loadEventEnd-0.
>
> We found that though this completes the timeline by including the  
> navigation data, a developer could not retrieve the detailed timing data  
> for each phase of the navigation from this object, like they could for  
> resources and scripts. Instead a developer would be forced to use  
> PerformanceTimeline for resources and scripts, and use  
> performance.timing for navigation data. Further, Resource and User  
> Timing were using higher resolution time than PerformanceTiming was. In  
> order to make all of the performance metrics more consistent and balance  
> compatibility, there has been discussions on creating a  
> PerformanceNavigationTiming interface that would fully participate in  
> the Performance Timeline and contain all the timing data in high  
> resolution time.
>
> This discussion was started on the mailing list:  
> http://lists.w3.org/Archives/Public/public-web-perf/2012Apr/0027.html.  
> In our last call, we overwhelmingly felt that such changes would be  
> better suited for the next version of the Navigation Timing spec,  
> instead of living in the Performance Timeline spec which had been scoped  
> to defining the uniform retrieval API and PerformanceEntry object.  
> Hence, I have made the changes suggested in the mail thread to  
> Navigation Timing 2 and have removed the section in Performance Timeline  
> related to navigation data.
>
>> Are we certain that the recent change to the spec (see above) is for  
>> the best? There should at least
>> be a fair chance to discuss the change before moving to CR.
>
> The working group had spent much time discussing how to create a uniform  
> interface for all performance metrics, which lead to the Performance  
> Timeline spec. At least, Microsoft and Google feel very good with the  
> current spec. Seeing that no issues had been raised against this spec  
> during the Last Call phase and since then, the working group felt that  
> it was time to move this spec to the next stage. This would be also be a  
> good signal for us to start creating implementations.
>
> However, if you believe there are spec issues that need to addressing,  
> please do raise them.
>
> Thanks,
> Jatinder


-- 
Sigbjørn Vik
Core Quality Services
Opera Software

Received on Saturday, 28 April 2012 19:20:56 UTC