[minutes] 20110420 Web Performance WG Teleconference #29

Web Perf Teleconference 4/20/2011

IRC log http://www.w3.org/2011/04/20-webperf-irc

Meeting Minutes: http://www.w3.org/2011/04/20-webperf-minutes.html

Attendees
Present
Christian, Jatinder, Nic, Cameron, Philippe, JamesS, JamesR, KarenA, Zhiheng, Arvind

Meeting Chair
Jatinder Mann

Regrets
Jason Weber

Scribe
Jatinder Mann

Contents
Topics
1. Announce starting Wednesday 2PM PST teleconf meetings next week for Page Visibility, Efficient Script Yielding and Display Paint Notifications. 
2. Feedback and discussion on Monotonic Clocks 
3. Feedback and discussion on proposed changes to navigationStart for the cross-domain redirect case. 
4. Feedback and discussion on Unified Timing API proposal. 

Summary of Action Items
 [NEW] ACTION: Jatinder to update Resource and User Timing specs to include Section 5.3 Monotonic Clock. [recorded in http://www.w3.org/2011/04/20-webperf-minutes.html#action03] 
[NEW] ACTION: Zhiheng to update Navigation Timing spec to ensure navigationStart is not zero'd out for x-domain redirect case. [recorded in http://www.w3.org/2011/04/20-webperf-minutes.html#action02]

Summary of decisions:
- We agreed to change Navigation Timing such that navigationStart is not zero'd out for cross-domain redirect cases. The security and privacy concerns are only in an edge case scenario and do not merit leaving the timing incomplete.

- We agreed to add a section on Monotonic Clocks in all three specs.

- We agreed to focus our attention to improve and stabilize the existing Resource Timing and User Timing specs rather than pursuing the Unified Timing proposal. The Unified Timing proposal would add restrictions to our ability to innovate these APIs in the future, as a change specific to one area will impact all areas. 
--------------------------------------------------------------------------------

<trackbot> Date: 13 April 2011

<Karen_> Meeting: Web Perf Teleconference 4/13/2011

<Karen_> scribe: Karen Anderson

<Karen_> ScribeNick:Karen

<Christian> also arvind is here

<Karen_> agenda:this

<plh> hi folks, I'm off site this afternoon and can't be on the phone for this hour

<plh> sorry about that

<Karen_> move to agenda 1

<Karen_> Zhiheng: there might be other navigation scenarios that we should cover with testing

<Karen_> Zhiheng: Some of these tests might be corner, but we should think about them more

<Karen_> Nic: some to think about would be around persistent connections

<Karen_> Nic: we do still need to add a check to the server redirect test to verify the origin server

<Karen_> Tony: Caching is not enforced on all UAs so this might be difficult

<Karen_> Tony: we might be able to fake this by adding pauses to the networking phases, or adding time in the load event

<Karen_> Nic: That sounds like a good idea. This is also similar to the test around the previous unload if there wasn't one

<Karen_> Zhiheng: We need to have tests for all of the MUST criteria of the spec.

<Karen_> Zhiheng: Would should have a log of tests that we don't have so there is a record of what might be missing, or we need to make those sections non-normative

<Karen_> Zhiheng: it's preferable to have the tests instead of changing the spec requirements

<Karen_> Nic: We agree

<Karen_> Tony: We should ask Philippe about this

<Karen_> Tony: Looks like we are missing previous document tests and page reload

<Karen_> ACTION: Zhiheng to investigate tests around persistent connections [recorded in http://www.w3.org/2011/04/13-webperf-minutes.html#action01]

<trackbot> Created ACTION-19 - Investigate tests around persistent connections [on Zhiheng Wang - due 2011-04-20].

<Karen_> ACTION: Tony to investigate tests around no previous document scenarios [recorded in http://www.w3.org/2011/04/13-webperf-minutes.html#action02]

<trackbot> Created ACTION-20 - Investigate tests around no previous document scenarios [on Tony Gentilcore - due 2011-04-20].

<Karen_> ACTION: Karen to update the page reload test to update the timings [recorded in http://www.w3.org/2011/04/13-webperf-minutes.html#action03]

<trackbot> Created ACTION-21 - Update the page reload test to update the timings [on Karen Anderson - due 2011-04-20].

<Karen_> Nic: Should we wait to add the navigationStart verification until after we settle that?

<Karen_> Nic: We haven't been able to get a full security review around the navigationStart issue as people have been OOF at Mix

<Karen_> move to agenda 2

<Karen_> Zhiheng: I don't think we would be adding additional sec or IP data by allowing NavStart

<Karen_> Nic: Does your sec team have no or little concern?

<Karen_> Zhiheng: 2 things, this can already be done; having the timing here doesn't make any attacks any easier

<Karen_> Christian: by not exposing this info then we can't actually measure the most basic nav scenario

<Christian> that was arvind

<Karen_> Arvind: Let's wait until MS can have the review and we can discuss more then

<Karen_> Nic: we should be able to do this before next week

<Karen_> move to agenda 3

<Karen_> Nic: it was brought up the issue that if the user changes the system clock then the subsequent timings are not in relation to the nav start time

<Karen_> Tony: We should have timings that play well with Date objects

<Karen_> Nic: IE implements the timing so that it is all relevant

<Karen_> Tony: the spec does have the recommendation to use UTC to support this

<Karen_> Zhiheng: what is the time skew?

<Karen_> Nic: the resolution of the Date object is not consistent which is one reason why there could be a skew

<Karen_> Nic: it could be beneficial to have a note in the spec to outline this difference as a warning to web devs

<Karen_> James: should we make it more explicit that the timings have different starting points

<Karen_> Nic: no complaints here

<Karen_> Zhiheng: don't think it's an issue with the spec currently and there isn't a strong dependency on the date object

<Karen_> Zhiheng: we shouldn't change the spec, but instead make a recommendation on the correct implementation

<Karen_> ACTION: Zhiheng to update the spec to include details on how the Nav Start should be implmented and how web devs should measure deltas [recorded in http://www.w3.org/2011/04/13-webperf-minutes.html#action04]

<trackbot> Created ACTION-22 - Update the spec to include details on how the Nav Start should be implmented and how web devs should measure deltas [on Zhiheng Wang - due 2011-04-20].

<Karen_> move to agenda 4

<Karen_> Nic: there were a few spec updates

<Karen_> Tony: waiting to hear more about the unified proposal first before feedback on the 4/5 updates

<Karen_> move to agenda 5

<Karen_> Tony: the motivation is too simplify the timings so that additions could be added at any time and not just these, to make this more future proof

<Karen_> Tony: this also makes it so that it is not on by default

<Karen_> Tony: different types of logs, app log and resource log. user is overloaded...anyway, start recording resource timings in that log, everything that hits the network goes into this log

<Karen_> Tony: you can stop or clear the log at any time. There are methods to get the data out of the log. It's similar to how it's speced now, but they've realized that there isn't really movement that they can land right now. So looking for something to tie it all together with the DOM, etc

<Karen_> Nic: It does reduce the functionality (good or bad) such as the initiator type, ids, or measures. But maybe this is good or bad...need to think it over

<Karen_> Nic: we do want to have something that is future proof. it might make it hard to extend in the future such as widgets for example and if you only wanted to blue widgets

<Karen_> Nic: it does give a more simplified view, but what if we had the current design and then the unified proposal is moved more to a script library

<Karen_> Tony: Does this mean that we don't need multiple ways to access the data? Explain what you mean by different view of things.

<Karen_> Nic: Assume we implement as speced today, the unified proposal could utilize the underlying data and then simplify the view, meaning a facade over what is really being stored

<Karen_> Tony: I think that's true, but let me think about it more. Part of it is picking how the API should look and what should that view expose. We are shooting to capture the same underlying data

<Karen_> Tony: the one contentious thing is whether to tie into the DOM. It could be a layered implementation and maybe it should. The question is how would this ultimately look.

<Karen_> Tony: It seems that MS is worried that the unification is limiting to future exposure. The design should be something that will scale and I would be interested in a use-case to help support that.

<Karen_> Nic: Pretend that we didn't implement NT, could that have fit into this? Some of it wouldn't like the redirect count and type. There could be others.

<Karen_> we all agree that we want a design that will fit what we are working on today and what could come down the road.

<Karen_> Tony: are UT and RT at a point that MS feels that we could land right now. We don't feel that way currently.

<Karen_> Nic: No, we aren't at 99%, if you asked us a month back...no we weren't ready to implement. But now, we think we are making good progress and we aren't quite ready to implement yet due to ongoing updates and open issues, but maybe 70% confidence

<Karen_> Nic: there isn't anything blocking us from implementation currently, but we would like to know what would block others from starting to implement now

<Karen_> Nic: Over the last month we have been making good progress, do you agree?

<Karen_> Zhiheng: I like the unifcation proposal, concern over RT is what we are going to expose. We don't have a good solution yet for xorigin, but agree that we are making good progress so far.

<Karen_> Zhiheng: it is not the top priority to have the unification proposal nailed and instead figure out the details on the inclusion list. We should still think about the unification, but prioritze accordingly.

<Karen_> Nic: agreed, we want to think about it, but not lose momentum on the RT details

<Karen_> Tony: let's all look over the proposal and give feedback next week. The problem is tricky and hopefully it will trigger some other ideas from everyone to get to a great solution

<Karen_> Nic: We still need to wait for Jatinder to be back to discuss deeper, but it's a great conversation piece for identifying holes in our current design

<Karen_> Zhiheng: The spec should stay in Candidate Recommendation for now given the open issues.

<Karen_> We didn't get to agenda 6 around UT.

<Karen_> rragent, make log public

<Karen_> rragent, draft minutes

Summary of Action Items
[NEW] ACTION: Karen to update the page reload test to update the timings [recorded in http://www.w3.org/2011/04/13-webperf-minutes.html#action03]
[NEW] ACTION: Tony to investigate tests around no previous document scenarios [recorded in http://www.w3.org/2011/04/13-webperf-minutes.html#action02]
[NEW] ACTION: Zhiheng to investigate tests around persistent connections [recorded in http://www.w3.org/2011/04/13-webperf-minutes.html#action01]
[NEW] ACTION: Zhiheng to update the spec to include details on how the Nav Start should be implmented and how web devs should measure deltas [recorded in http://www.w3.org/2011/04/13-webperf-minutes.html#action04]

Received on Wednesday, 20 April 2011 23:03:51 UTC