Re: About window.performance namespace

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.


>    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.

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.

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?

>   * 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

Received on Monday, 20 December 2010 08:35:24 UTC