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

On Tue, 15 May 2012 20:55:53 +0200, Arvind Jain <arvind@google.com> wrote:

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

Thanks for the summary, that seems like a concise conclusion.

For simplicity, let's call PerformanceNavigation the "old API", and  
PerformanceNavigationTiming the "new API".

Jatinder mentions that sites have already taken dependencies on the old  
API, which in practice means that the old API has to be supported for the  
next 10-20 years, and new implementations need to add support for this.  
For the benefit of all, the old API should thus be documented somewhere,  
and we should ensure that newer specifiations are not incompatible with  
this.

At the same time, we want to evangelize the new API, and move developers  
away from the old. The longer we wait with doing this, the more permanent  
the old API will become, and the more problems will it cause in the  
future. If we want to deprecate it, we should do so ASAP. In particular,  
if we ship a final version of the spec with the old API, this will make a  
significant negative difference. We already have the new API, which would  
be the recommended one. Shipping a recommendation (a final specification)  
with a non-recommended, old API would be a contradiction in terms.

Luckily, we can achieve all of the above, without breaking any existing  
sites. We already have the documentations of the old API, so we set that  
aside somewhere (as a Note[1]), and we update the spec to use the new API.  
Implementations may still support the old API if they wish, but it will  
never reach recommended status. This means no extra work for existing  
implementations (they only need to add the new API, which they need to add  
in any case), and we will be able to push the recommended, new API to  
recommended status faster. If we are lucky, a few years down the road, new  
implementations might even not have to support the old API. The downside  
is that it will take a bit longer for the specification to become  
recommended, but when it does, it will be a better specification.

The goal here is to write standards for the betterment of the Web, for the  
long term. Shipping a non-recommended recommendation might look tempting  
right now, but if we do so, web developers 5 years down the road will  
curse the spec writers. I believe the right action long term is to invest  
in a proper spec.

For the record, some of the problems I see with a duplicate API:
All parties have to support the deprecated API for all future
Examples and tutorials wrong and confusing forever after, frameworks for a  
long time
Twice the potential for bugs and browser incompatibilities
The exact problem the group tries to avoid (incompatibility with other  
specs and confusing APIs) will instead be aggravated

[1] Example W3C Note: http://www.w3.org/TR/2010/NOTE-webdatabase-20101118/

-- 
Sigbjørn Vik
Core Quality Services
Opera Software

Received on Wednesday, 16 May 2012 15:20:33 UTC