Re: About window.performance namespace

On Fri, Dec 17, 2010 at 2:03 AM, Sigbjørn Vik <sigbjorn@opera.com> wrote:

> 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 ;)


   and you are still expecting Santa's gift this year? ;)



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

  How about secureConnectionStart?



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


   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.
  * 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.
  * Having the top level namespace, i.e., window.performance, replaceable
make unittest easier.

cheers,
Zhiheng




>
> --
> Sigbjørn Vik
> Quality Assurance
> Opera Software
>
>