Re: About window.performance namespace

   Pls find my $0.02s inline.

On Mon, Dec 20, 2010 at 12:34 AM, Sigbjørn Vik <sigbjorn@opera.com> wrote:

> On Sat, 18 Dec 2010 06:11:22 +0100, Zhiheng Wang <zhihengw@google.com>
> wrote:
>
>  On Fri, Dec 17, 2010 at 2:03 AM, Sigbjørn Vik <sigbjorn@opera.com> wrote:
>>
>>  I have a slight preference for "httpsHandshakeStart" and
>>> "networkEncryptionStart", but I don't really like any of the alternatives
>>> above. :/ Are there any exisiting API naming conventions we can reuse?
>>>
>>>
>>  How about secureConnectionStart?
>>
>
> That works for me.


   Done.


>
>
>
>    I have to say there is not yet a clear answer here. There are a couple
>> points bought up but so far none of them could clearly drive the
>> decision one way or the other, so we are trying to walk over a fine line
>> among them.
>>
>>  * Applications in the future might rely on these timing attributes for
>> monitoring, diagnostics or deciding how a page should behave. Allowing
>> anyone to arbitrarily write to them could cause problem for naive
>> developers. For example, one conformance requirement so far is the correct
>> ordering of the time stamps. That assumption can easily be broken if
>> another
>> script simply sets navigationStart to 0.
>>
>
> We might add more datapoints or timing interfaces in the future. Any
> scripts relying on attributes coming one after the other without checking
> that it is processing the right attribute will then break anyhow.

We should consider making the spec in such a way that such a serial
> processing model is discouraged, and/or explicitly tell authors not to write
> scripts that way. Confusing web authors who are using JS in the right way,
> in order to cater for web authors who are using the spec in the wrong way,
> does not seem like a good tradeoff to me.
>

   Upcoming additional interfaces from other frameworks can be added to a
new separated namespace. Like
document.lastModified<http://dev.w3.org/html5/spec/Overview.html#dom-document-lastmodified>
,
it makes sense to make these attributes read-only if we consider them
properties of the page. Having window.performance readable
is simplybecause we don't want to break existing pages.

   Sorry that my comments above causes confusion about the requirement of a
serial processing model. Please never mind them.
Ordering is not a conformance requirement (for the same reason you bought up
here) but something we were discussing to leverage
in conformance testing. That said, some attributes are just by definition to
be ahead of others, like navigationStart.
   It is nice to simply write:
*   onload = loadEventStart - navigationStart;*
*
*
   instead of
*   var onload;*
*   if (loadEventStart > navigationStart) {*
*    onload = loadEventStart - navigationStart;;*
*  }*


>
> On the other hand, I see valid use cases for overwriting the sub-objects.
> For instance in my debug environment, I know one of the attributes is way
> off, so I want to change/overwrite that, in order to see the correct output
> from the third party timing script.
>

    Instead of changing/overwriting individual attributes, you can create a
mock performance object and swap out window.performance in the debugging
environment.
It takes some extra work but testing/debugging probably worth it. :-)


>
> For the record, I still don't understand the full implications of making
> the parent replaceable, but not the children. Does this for instance mean
> the children will be copied across to the new object which is replacing the
> parent?


   Good question that I am not sure about, even though I am expecting the
attributes under timing/navigation to be copied as well. Other folks could
probably help clarify?

cheers,
Zhiheng


>
>
>   * Existing pages using window.performance (or any other names for that
>> matter) will break if it's read-only. The possibility is rather low (<
>> 0.01%) but it's there.
>>
>
> Agreed, valid point for having the object replaceable.
>
>
>   * Having the top level namespace, i.e., window.performance, replaceable
>> make unittest easier.
>>
>
> Not quite sure how it would help having window.performance replaceable,
> when the sub-objects cannot be replaced.
>
> I suggest that if we want to make window.performance replaceable, we make
> it 100% replaceable, including all attributes on it.
>
>
> --
> Sigbjørn Vik
> Quality Assurance
> Opera Software
>
>