- From: Zhiheng Wang <zhihengw@google.com>
- Date: Wed, 20 Apr 2011 10:46:07 -0700
- To: Jatinder Mann <jmann@microsoft.com>
- Cc: "public-web-perf@w3.org" <public-web-perf@w3.org>
- Message-ID: <BANLkTin933RaVyt4RvE4XbUPxWc5kJ4Ocw@mail.gmail.com>
Per Action Item #4, the spec now includes some discussion about the monotonic clock: https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html#mono-clock <https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html#mono-clock> Please check it out and we can discuss in today's meeting. cheers, Zhiheng On Wed, Apr 20, 2011 at 10:10 AM, Jatinder Mann <jmann@microsoft.com> wrote: > Web Perf Teleconference 4/13/2011 > > IRC log http://www.w3.org/2011/04/13-webperf-irc > > Meeting Minutes: http://www.w3.org/2011/04/13-webperf-minutes.html > > Attendees > Present > Karen, Nic, Zhiheng, Christian > > Regrets > Jatinder Mann > Jason Weber > > Scribe > Karen Anderson > > Contents > Topics > 1. NavigationTiming Test updates > 2. NavigationTiming navigationStart in cross-origin redirected navigations > 3. NavigationTiming wall-clock time > 4. Feedback on 4/5 updates to Resource Timing > 5. Feedback on Unified Timing Proposal > 6. Discussion on User Timing > 7. Any other business > > 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] > > > -------------------------------------------------------------------------------- > > <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 17:46:37 UTC