Re: NavigationTiming update with PerformanceEntry

On Tue, Jul 12, 2011 at 11:02 AM, Nic Jansma <Nic.Jansma@microsoft.com>wrote:

>  Hi folks,****
>
> ** **
>
> With the recent updates to the NavigationTiming spec (
> http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html),
> one of the changes is that NavigationTiming now participates in the
> Performance Timeline (
> http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html#sec-performance-timeline
> ).****
>
> ** **
>
> To do this, NavigationTiming must somehow be exposed as a PerformanceEntry,
> which has these attributes:****
>
> ** **
>
> interface *PerformanceEntry* {****
>
>   readonly attribute DOMString name;****
>
>   readonly attribute unsigned long long startTime;****
>
>   readonly attribute unsigned short entryType;****
>
>   readonly attribute unsigned long long duration;****
>
> };****
>
> ** **
>
> As of today, there are two attributes that hang off of window.performance
> related to NavigationTiming:****
>
> **·         **window.performance.navigation - Metadata for the navigation,
> such as type redirectCount****
>
> **·         **window.performance.timing - Timestamps of phases of the
> navigation****
>
> ** **
>
> My question for the group is: *Should we have window.performance.timing
> inherit from PerformanceEntry, and thus also have the name, startTime,
> entryType and duration attributes?*
>
> ** **
>
> The reason to do this would be to have consistency for the Performance
> Timeline, where all objects inherit form PerformanceEntry.****
>
> ** **
>
> However, the downsides of doing this would be:****
>
> **1.       **The performance.timing object changes from *all* timestamps
> to a mixture of timestamps, durations, strings and enums (shorts).****
>
> **2.       **Consumers of the interface wouldn't be able to blindly sort
> all of the timestamps under performance.timing and place them on a timeline,
> as they're now a mixture of types.****
>
> **3.       **The processing model (
> http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html#processing-model)
> for NavigationTiming would have to be updated and might be more confusing
> (for example, section 16.f refers referrs to zeroing out all
> performance.timing attributes)****
>
> **4.       **The Vendor Prefixes section (
> http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html#vendor-prefixes)
> talks about the naming standard for attributes added to performance.timing.
> The PerformanceEntry attributes don't follow this standard.****
>
> ** **
>
> One way to work around this could be instead of updating performance.timing
> to inherit from PerformanceEntry, we leave it as-is.
>

   I for one don't think it's necessary to follow the inheritence here, for
all the reasons you mention. Besides, the extra interfaces create redundancy
for the spec itself.


> Instead, if the user requests getEntry() and gets back a PERF_NAVIGATION
> object, then-and-only-then do we return a PerformanceTiming object that
> inherits from PerformanceEntry.
>
>
>

     This can be specified in ResourceTiming or UserTiming instead, when we
bring up the getEntry() interface?

cheers,
Zhiheng


>
>
> ** **
>
> Another possibility is to have performance.navigation be the object that
> inherits from PerformanceEntry.****
>
> ** **
>
> Thoughts?****
>
> ** **
>
> - Nic****
>