RE: About window.performance namespace

This is great feedback. I think the term secureConnectionStart is an appropriate name, given that it signifies the beginning of the secure session being established.

-----Original Message-----
From: public-web-perf-request@w3.org [mailto:public-web-perf-request@w3.org] On Behalf Of Sigbjørn Vik
Sent: Monday, December 20, 2010 12:35 AM
To: public-web-perf
Subject: 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 19:21:11 UTC