Re: Unified Timing Proposal

On Wed, Apr 20, 2011 at 11:01 AM, Nic Jansma <Nic.Jansma@microsoft.com>wrote:

>  My worries about designing an interface for future extensibility still
> hold though.  While we could update the interface right now, before we've
> shipped, with the ability to allow metadata (such as redirectCount), what if
> we had finalized on the Unified Timing interface, and were only just now
> coming to NavigationTiming?  We couldn't break the existing Unified Timing
> object model, so we would either have to break compatibility or extend it in
> a way that might break existing scripts.
>

This is why we discuss them ahead of time. It's great you're able to help us
catch these requirements before we finalize anything. Thanks!


> Continuing with this scenario, let's say we finalize on the below additions
> to the Unified Timing interface that allows for metadata, and User Timing
> and Resource Timing implement it.
>
>
>
> Now we want to measure Widgets.  Widgets have timing information, but they
> also require a strongly-typed timing object for one of the following
> reasons:
>
> ·         We want to have a function on each object, such as
> getWidgetColor()
>
> ·         We want to allow others to be able to extend the WidgetTiming
> interface with their own functionality by using the Prototype of the object
>
>
>
> Unfortunately, I don't think we could support either of these with the
> loosely-typed array-based interface.  We would have to either update the
> interface to support strongly-typed objects, or skip on that functionality.
>

I don't think supporting strong typing is worthwhile for any of the Timing
specs. The goal is to collect data on the client side that are otherwise
unavailable to the site's owner. The data are only useful if they can be
pinged back to the site. JSON seems to be the best way to do this, so
standardizing on it seems like the approach we should take.

BTW, how about calling these Client Side Metrics?

James