- From: Sigbjørn Vik <sigbjorn@opera.com>
- Date: Fri, 17 Dec 2010 11:03:20 +0100
- To: public-web-perf <public-web-perf@w3.org>
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