Re: [NavigationTiming] a couple questions

On Wed, Nov 10, 2010 at 8:32 AM, Tony Gentilcore <tonyg@google.com> wrote:

> We discussed naming/location on a previous call. IIRC, here were the
> points we came to (others please keep me honest here):
>
> - Hang it under console? The goal of the performance object is to
> expose information to the DOM in production. This is distinct from
> console which only interacts with the debugging console during
> development.
> - Hang it under document? There are subtle differences between window
> and document lifetimes (for instance a late document.write can replace
> the document). The performance information outlasts a document, so it
> didn't make a whole lot of sense there. However, I don't recall any
> strong objections to moving it if we want to revisit.
> - Will global performance conflict with many sites? We discussed
> allowing it to be replaceable so that if a site were to define var
> performance or window.performance, it would override the built-in.
> This would mitigate all but the most pathological conflicts.
> Unfortunately, I don't recall where we ended up on this discussion and
> can't find anything one way or the other in the spec.
>

   The caveat is, making it replaceable allows other content on the page to
alter global timing
information. Some techniques (hasOwnProperty?) may help mitigate the effect
but it's some burden
to all developers to make sure the time is authenticated.

cheers,
Zhiheng





>
> Another alternative which I don't think we discussed would be to hang
> them directly under navigator. e.g. navigator.timing,
> navigator.navigation...
>
> -Tony
>
> On Wed, Nov 10, 2010 at 2:20 AM, Sylvain Hellegouarch <sh@defuze.org>
> wrote:
> >
> >
> > On Wed, Nov 10, 2010 at 11:16 AM, Anne van Kesteren <annevk@opera.com>
> > wrote:
> >>
> >> On Wed, 10 Nov 2010 07:11:25 +0100, Jonas Sicking <jonas@sicking.cc>
> >> wrote:
> >>>
> >>> One solution would be to stick it on the document object. Another to
> >>> come up with a more exotic name though I have to admit any good
> >>> suggestions escape me at the moment.
> >>
> >> One idea I had was to put it on window.console if we are going to
> >> standardize parts of window.console anyway since the performance API is
> >> mostly for debugging and figuring out what is going on.
> >>
> >
> >
> > Most likely indeed. However, I was wondering if it would make sense to
> use
> > the performance API as a monitoring platform in production as well. It
> could
> > offer some interesting pieces of information. Mind you, I'm not familiar
> > with its impact on the resource processing itself.
> > --
> > - Sylvain
> > http://www.defuze.org
> > http://twitter.com/lawouach
> >
>