Re: About window.performance namespace

On Thu, 16 Dec 2010 23:56:40 +0100, Zhiheng Wang <zhihengw@google.com>  
wrote:

>    Sounds good to me. I will have these two items updated if everyone  
> agrees
> at the end of 12/17.

Sorry to be a spoil-sport, but I have some comments below ;)

> On Thu, Dec 16, 2010 at 2:52 PM, Anderson Quach  
> <aquach@microsoft.com>wrote:
>
>> Thanks Zhiheng, we want to solidify on this decision by the end of day
>> Friday 12/17/2010 in order to get to Last Call for the Navigation Timing
>> specification.
>>
>>
>>
>> Also, merging some thoughts on a related thread. It would be great to  
>> have
>> a more specific name for handShakeStart, sslHandShakeStart is  
>> appropriate.

The "s" in "shake" should be lowercased, as "Handshake" is one word (it  
currently is in the spec).

The proper name (in most cases) would be tlsHandshakeStart, TLS is 11  
years old. An in about 5 years it is going to be xyzHandshakeStart. Tying  
the name to the specific protocol sounds like a bad idea. Not certain I  
have a better alternative though. It provides a network layer encryption  
(networkLayerEncryptionHandshakeStart is too long), is used on https  
(httpsHandshakeStart could work), but the "s" in "https" just means  
"secure" (secureHandshakeStart is meaningless, confusing and could apply  
to several handshakes). Then again, lots of people (misguidedly) still use  
"SSL" today when they mean "TLS", so one could argue that "SSL" is a  
generic term for network layer security (just as "hoover" is a generic  
term for a "vacuum cleaner").

"networkHandshakeStart" might be used about several network handshakes.  
"networkEncryptionStart" might work, we might be able to do withouth the  
word "handshake" in there, as "networkEncryptionHandshakeStart" is too  
long.

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?

>> *From:* public-web-perf-request@w3.org [mailto:
>> public-web-perf-request@w3.org] *On Behalf Of *Zhiheng Wang
>> *Sent:* Wednesday, December 15, 2010 9:57 PM
>> *To:* public-web-perf
>> *Cc:* Jonas Sicking; Sigbjørn Vik; Simon Pieters
>> *Subject:* About window.performance namespace
>
>
>>    Proposal:
>>      * window.performance will be replaceable
>>      * window.performance.timing and window.performance.navigation will  
>> be kept read-only.
>>
>>    Having window.performance replaceable avoid breaking existing
>> javascripts. Keeping the timing and navigation objects read-only
>> does not guarantee the integrity of timing attributes but makes forging
>> these interfaces less trivial.

Would you mind sharing the thoughts behind this? It seems confusing to me  
to have the master replaceable, but the children not. Does this mean that  
if I make a copy of an existing object, and name the new copy  
"performance" in the global namespace, the new copy might not be identical  
to the old? (Since the timing and navigation sub-objects will not be  
copied across?) Or would this trigger a JavaScript exception? How would we  
communicate this to the poor confused web developer?

What are the issues with forging these interfaces? Do we not want to allow  
frameworks to extend (i.e. replace) these interfaces?

-- 
Sigbjørn Vik
Quality Assurance
Opera Software

Received on Friday, 17 December 2010 10:03:49 UTC