16:05:20 RRSAgent has joined #webperf 16:05:20 logging to http://www.w3.org/2010/09/29-webperf-irc 16:05:34 rrsagent, set logs world-visible 16:05:52 meeting: Web Performance Working Group #04 16:06:35 chair: ArvindJain 16:06:39 chair: JasonWeber 16:06:52 scribe: AndersonQuach 16:07:03 present: ArvindJain 16:07:06 present: SteveSouders 16:07:11 present: AndersonQuach 16:07:19 list the agenda 16:07:44 +??P30 16:08:00 clear the agenda 16:08:07 present: Zhiheng 16:08:46 zhiheng has joined #webperf 16:09:40 agenda+ Feedback on the processing model. 16:10:05 agenda+ Feedback on the lifetime management of the navigation timing, tied with the lifetime of the document object and interactivity with the unload event. 16:10:11 agenda+ Resource Timing scenarios. 16:10:18 agenda+ User Timings. 16:10:23 agenda+ F2F meeting updates. 16:10:29 agenda+ TPAC meeting updates. 16:10:34 agenda+ Any other business. 16:10:45 zakim, save agenda 16:10:52 ok, AndersonQuach, the agenda has been written to http://www.w3.org/2010/09/29-webperf-agenda.rdf 16:12:30 list the agenda 16:13:56 next agendum 16:14:19 AndersonQuach: going thru the feedback in the web perf email list. 16:15:02 AndersonQuach: That way the timeline in a cached DNS scenario would go from looking like this: 16:15:07 AndersonQuach: (fs,dls,dle)---(cs)---(ce) 16:15:36 (fs)---(dls,dle,cs)---(ce) 16:15:58 AndersonQuach Let domainLookupStart, domainLookupEnd, be the same value as connectStart. 16:16:12 AndersonQuach Let connectStart, connectEnd be the same value as requestStart. 16:17:30 + +1.650.214.aacc 16:17:50 Zhiheng question, domainLookup, connectStart already init to fetchStart and have the same value, what's the scenario? 16:20:48 Zhiheng: how would we test if we were to snap to the latest timestamp? 16:20:57 AndersonQuach: good question. 16:21:21 tonyg has joined #webperf 16:22:30 AndersonQuach: can be tested by breaking down case by case, i. dns cached, ii. connection established iii. doc cached. 16:25:30 Tony: the issue if we have time between phases in the event of these cached scenarios 16:26:01 Zhiheng: goal, network timing scenario, fine putting them into fetchStart, the variable in this case for dns and connection 16:26:32 Zhiheng: now the user agent will have wait for the timestamp to fill out the values. 16:27:52 AndersonQuach: so you're concerned with the implementation issue, difficultly? 16:27:58 Zhiheng: yes 16:28:38 Tony: dns lookup may be zero in the cache, the question is, in that case do we snap to the end or beginning of the time, either option seems fine. i don't understand why it's perferable to snap to the end. 16:29:27 AndersonQuach: would love to get feedback from other browser implemetnations. 16:30:03 present: tonyg 16:30:48 Zhiheng: caching scenario may have different starting points, cache miss, request start the browser something to the network. 16:31:15 Zhiheng: always starting the requestStart when the browser does a cache lookup 16:31:32 Zhiheng: cache look up can come before the fetch 16:33:20 AndersonQuach: IE is abstracted from the networking request 16:33:31 Zhiheng: how about chrome 16:34:12 Zhiheng: can you differentiate lookup times from fetchign resource from cache or fetched the network 16:34:28 Tony: we could, we didn't want to for privacy reasons 16:34:58 Zhiheng: should we start from the look-up from cache or from when we fetch from the network, in the case of a cache miss. when should we start the requestStart timestamp 16:35:57 Tony: i believe in the current implementation, tell the http stack to get something, or it may hit the cache, or hit the network. we're timing the http stack api, get me a request. in that request time, we're including disk cache lookup 16:36:01 Zhiheng: we have some agreement 16:36:22 AndersonQuach: requestStart will have both the cache hit and cache miss time 16:36:51 Zhiheng: according to the html5 spec, fetchStart may come before requestStart 16:37:01 Tony: in chrome would be impossible for request to start before fetch 16:37:41 Zhiheng: instead of fetchStart we want to come up with another name, we are referring to the fetch process in html5 16:37:58 Tony: maybe, i'm not sure if our publicly facing names need to correspond. 16:38:04 Tony: fetch start makes sense in our api 16:39:19 AndersonQuach: it would be okay to use fetch, as long as we are clear about its definition 16:39:30 Zhiheng: will look up and provide a reference 16:39:33 next agendum 16:41:31 AndersonQuach: feedback, i think you meant the lifetime of the current document object and not the window object 16:41:47 Tony: I think it's tied to the window not the document. 16:42:26 Zhiheng: when you navigate across different documents, update timings. for a new document, a new window should be created. 16:42:32 Tony: I need to check on these. 16:43:15 http://dev.w3.org/html5/spec/browsers.html#garbage-collection-and-browsing-contexts 16:45:49 Zhiheng: during the unload which navigation timing object should we provide, we should be reading the timing of the current browsing context 16:46:14 AndersonQuach: we agree that it should be tied to the current browsing context 16:47:37 Tony: HTML5 spec out pretty well, page cache in web kit and fast back in mozilla. when you do go back, fast back, you would get the navigation timing on the original load rather than generate a new one on a fast back. everything that was in the dom was restored back up. we'll need to cover this in the spec. 16:47:51 Tony: search for page hide and page show events 16:47:56 AndersonQuach: ok 16:49:21 AndersonQuach: provide feedback through email on the clarification on the language. 16:51:15 list the agenda 16:51:33 move to agendum 5 16:52:04 plh has joined #webperf 16:52:27 AndersonQuach: use the f2f to talk about best practices and test cases. 16:52:37 Zhiheng: list the goals for each items. 16:52:54 AndersonQuach: use the time to build out the list of goals and successes 16:53:55 AndersonQuach: browser implementation neutral, compatible time phases 16:54:42 AndersonQuach: use the meeting to also close on open issues 16:55:28 JasonWeber: also treat the spec, section by section and talking about it with everyone in the room and agree on the content of each section says. sign-off on the design and be confident when we publish this out. this will be aligned with the implementation with ie9 and chrome. 16:55:32 Zhiheng: sounds good 16:55:40 JasonWeber: that can take 1-2hrs on 10/5 16:55:45 present: JasonWeber 16:56:28 JasonWeber: make it a priority, start with open issue, go with spec review phase, and then we close on that we can move to best practices and test cases and other areas. i'm very excited pulling off the vendor prefix, for the next ie platform preview. 16:56:33 Zhiheng: that would be awesome. 16:56:38 Tony: yeah definitely. 16:56:56 list agenda 16:57:16 ArvindJain: are we having the meeting there? Microsoft will be remotely attending 16:57:22 move to agendum 6 16:57:43 JasonWeber: Anderson and myself do not plan on attending, as we will meet face to face in mountainview 16:57:57 Zhiheng: i need to confirm with my management 16:58:18 JasonWeber: we plan on attending remotely, Microsoft will be largely represented at TPAC in other areas 16:58:26 ArvindJain: we'll get back to you on the attendence 16:58:58 - +1.650.823.aabb 16:58:59 - +1.650.214.aacc 16:59:00 - +1.650.253.aaaa 16:59:05 -[Microsoft] 16:59:06 -??P30 16:59:07 RWC_web-per(WPWG)12:00PM has ended 16:59:09 Attendees were +1.650.253.aaaa, +1.650.823.aabb, [Microsoft], +1.650.214.aacc 16:59:09 regrets: njansma 20:09:31 RRSAgent has joined #webperf 20:09:31 logging to http://www.w3.org/2010/09/29-webperf-irc 20:09:36 rrsagent, draft minutes 20:09:36 I have made the request to generate http://www.w3.org/2010/09/29-webperf-minutes.html AndersonQuach