Re: Unified Timing Proposal

Thanks for the feedback. I think we can address all of these issues with a
few more tweaks. I'll update the document with these later this week.

On Thu, Apr 14, 2011 at 3:10 PM, Nic Jansma <Nic.Jansma@microsoft.com>wrote:

>  Thank you Tony and James.  Your proposal has given us a lot of food for
> thought.  The fact that we're discussing a simpler interface such as this is
> a good reason to step back and consider the direction we're taking the
> UserTiming (UT) and ResourceTiming (RT) specs.  Maybe they're getting too
> complex?
>

For me, the issue is more that they all do roughly the same thing, but the
implementations are entirely independent.


> One of our main concerns with the Unified Timing Proposal is that it will
> reduce some of the functionality we have been building into the RT and UT
> specs, such as:
>
> ·         ResourceTiming: Initiator type
>
> ·         ResourceTiming: Initiator element IDs
>
These are metadata. I think if we just add a new dimension to Unified
Timing, we can collect these. For each object key, we already collect a list
of marks. In addition, we could also collect a list of metadata for each
object key. These would just be key-value pairs that could easily be
serialized to JSON. The metadata available would depend on which spec is
involved. It'd look like performance.navigation does now, except that you'd
access it through Unified Timing instead.

BTW, we should consider dropping the word "Timing" from all of the specs.
We're collecting other data besides timing in a lot of the cases.

> ·         ResourceTiming: The onBufferFull callback
>
We can add that back. The design doesn't preclude it.

>  ·         UserTiming: Having separate concepts of marks and measures
> (allowing measures to specify arbitrary start and end marks, clearing them
> independently, etc)
>
Again, the design doesn't preclude supporting these. We can add the ability
to delete individual object keys if that's needed. Likewise, we could add
the ability to create measures from arbitrary marks.

If we can agree on the design, then we talk about the tradeoffs of
individual features like these.

I've been under the impression that we expect most people to just ping back
the data they collect. I wasn't expecting people to do a lot of analysis or
create or remove measures dynamically on the client side.

>  ·         The ability to easily separate UserTiming nodes from
> ResourceTiming nodes (I could see this being a larger problem as we add
> additional types to the Unified interface)
>
Metadata should address this.


>  As you mention, one of the goals of the Unified Timing proposal is to
> allow easy expansion for future timing-related interfaces.  We agree that it
> would be great to design with future expansion in mind, but at the same
> time, we are worried about the constraints it may place on future
> interfaces.
>
> As an example, let's pretend for a moment that NavigationTiming hasn't been
> designed yet, and the Unified Timing interface exists for UT and RT.  The
> question is: Would we be able to fit NavigationTiming into the Unified
> Timing interface?  We could add a new type (such as "Document") with all of
> the performance.navigation.timing attributes as marks.  The problem comes
> with the other metadata we provide for NavigationTiming -- such as
> performance.navigation.type and redirectCount.  I consider them essential
> attributes of the navigation, but don't see a way of incorporating them into
> the interface.  We could stick them in as "marks", but that would confuse
> timestamps with navigation metadata.  Would future interfaces be constrained
> by similar issues?
>
Yeah, adding a "Document" object key would be my plan for Navigation Timing.
With that, things like type and redirectCount become metadata on the
"Document" object key.


> One thought we have is that if we build the right underlying support into
> the existing UT and RT interfaces, JavaScript library authors could easily
> release a library looking similar to the Unified Timing proposal that would
> simplify the view of the three interfaces.
>
I think we should try to minimize the interface as much as possible. It
means simpler implementations, less surface area for bugs, and simpler user
documentation.

Finally, if we go down this route, we will still have to have separate User
> Timing and Resource Timing specs (to get the specifics of their interactions
> correct), as well as a new Unified Timing proposal/spec.  UT and RT would
> then be dependent on the Unified Timing proposal being finalized, which will
> cause some delay in moving these all forward.
>

Once we finalize something, we're pretty much stuck with it forever. It's
important we get it right from the beginning. A little extra work now will
save a lot of pain down the road.

James