RE: [NavigationTiming] .navigation and .timing

Hi Olli,

Thank you for your feedback.  As part of the working group, we have discussed several possibilities for the overall organization of the performance namespace.

Some of the benefits of keeping .navigation separate from .timing are:
* The characteristics of the navigation (type and # of redirects) are logically separated from the compete navigation timeline.
* All of the attributes in .timing are UTC timestamps, and can be sorted to visualize the navigation timeline.  Including the .navigation characteristics in the same namespace would require you to filter some out.
* A developer that is interested in packaging up and analyzing the data on their servers could easily JSON.stringify either one or both of the interfaces -- they have the choice.
* We may wish to expand either of these interfaces in the future, so keeping them separate gives us some flexibility.

- Nic

-----Original Message-----
From: public-web-perf-request@w3.org [mailto:public-web-perf-request@w3.org] On Behalf Of Olli Pettay
Sent: Sunday, March 20, 2011 4:06 AM
To: public-web-perf@w3.org
Subject: [NavigationTiming] .navigation and .timing

Hi all,


I wonder why there is window.performance.timing (which is a very generic name), and not just window.performance.navigation which could contain all the information?

I assume window.performance itself is there so that we can add later new features to it, like painting or something related to javascript handling.
But if we add window.performance.painting, window.performance.timing has nothing to do with that, only with .navigation.
And that is strange.

If .navigation and .timing were merged, in the future we could end up something like interface Performance {
   readonly attribute PerformanceNavigation navigation;
   readonly attribute PerformanceScripting  scripting;
   readonly attribute PerformancePainting;  painting; }; and all the attributes would have clearly distinct meaning.





-Olli

Received on Tuesday, 22 March 2011 23:48:36 UTC