16:06:26 <RRSAgent> RRSAgent has joined #webperf
16:06:26 <RRSAgent> logging to http://www.w3.org/2010/09/22-webperf-irc
16:06:54 <AndersonQuach> meeting: Web Performance Working Group Teleconference
16:06:56 <tonyg> tonyg has joined #webperf
16:07:03 <AndersonQuach> chair: "Arvind"
16:07:09 <AndersonQuach> chair: "JasonWeber"
16:08:29 <AndersonQuach> regrets: "Arvind"
16:08:32 <AndersonQuach> regrets: "JasonWeber"
16:08:35 <AndersonQuach> regrets: "plh"
16:09:48 <AndersonQuach> agenda+ Follow-up on feedback on requestCount and uniqueDomains attributes.
16:10:01 <AndersonQuach> agenda
16:10:36 <AndersonQuach> list the agenda
16:11:28 <AndersonQuach> agenda- 5
16:11:32 <AndersonQuach> agenda- 6
16:11:45 <AndersonQuach> agenda+ Follow-up on feedback on requestCount and uniqueDomains attributes.
16:12:16 <AndersonQuach> agenda+ Follow-up on feedback on requestEnd and responseStart.
16:12:22 <AndersonQuach> agenda+ The lifetime management of the navigation timing. What timing should be accessible at which phase of the document loading.
16:12:34 <AndersonQuach> agenda+ Resource Timing scenarios.
16:12:46 <AndersonQuach> agenda+ user timings scenarios
16:12:49 <AndersonQuach> agenda+ F2F meeting updates / agenda
16:13:02 <AndersonQuach> agenda+ Additional business
16:13:08 <AndersonQuach> next agendum
16:13:51 <AndersonQuach> Zhiheng: not sure if it is useful, I do not have a preference either way
16:14:20 <AndersonQuach> NicJansma: thoughts about additional helper metrics for navigation timing?
16:14:43 <AndersonQuach> Zhiheng: the value of the two attributes is marginal value
16:14:54 <AndersonQuach> present: "SteveSouders"
16:14:58 <AndersonQuach> present: "Tony"
16:15:23 <AndersonQuach> SteveSouders: why not lump it in now, it makes sense to have it in navigation timing, it's a state not specific about any resources, it's a stat about the overall page
16:15:37 <AndersonQuach> SteveSouders: if i take a step back, i would put these attributes in navigation timing
16:17:17 <AndersonQuach> NicJansma: that was our original intention, to help describe why the page had been faster or slower, the feedback is JasonSobel feels it not useful, however not opposed. Nik Matsievsky from Webo mentioned he would value these attributes.
16:17:50 <AndersonQuach> NicJansma: No privacy concern or security issue noted so far, may require additional deeper dive. Not expensive to implement.
16:18:17 <AndersonQuach> Tony: Not opposed, does resource timing make this redundant. if we add it now, we'll make sure it's not redundant.
16:18:59 <AndersonQuach> Zhiheng: I have the same concern with Tony. If the resource fetched from cache, is that counted as request, that may reduce the value of what we are looking for and the bottle neck on the page. we need to work on the details on these two metrics.
16:19:18 <AndersonQuach> Tony: If we do indicate if its from the cache we have concerns of privacy information.
16:19:34 <AndersonQuach> NicJansma: IE9 have number of all the resources.
16:20:13 <AndersonQuach> AndersonQuach: the two metrics complement each other.
16:20:43 <AndersonQuach> SteveSouders: the attribute is called requestCount, sounds like network access. if the attribute is about resources, we should call it resource count.
16:21:07 <AndersonQuach> NicJansma: We cannot split out resource that came from network or via cache, it would need to be appropriately named resourceCount.
16:21:15 <AndersonQuach> Tony: this never decrements.
16:21:33 <AndersonQuach> NicJansma: anytime thru an xhr, or img source, or get an external resource we increment by one.
16:22:33 <AndersonQuach> AndersonQuach: next step, Anderson will propose the recommended text for the navigation timing to the spec.
16:22:48 <AndersonQuach> NicJansma: do we think this has high value? or questioning it?
16:23:31 <AndersonQuach> Tony: if we have a flat list of resource timings, like resourceTiming.length, however if we decide that we cannot have a flat list in resource timing. then i think it is high value. it's important information to convey. i much rather count the length of the resources.
16:23:37 <AndersonQuach> SteveSouders: good point.
16:23:46 <AndersonQuach> Zhiheng: adding a counter to resource timing instead.
16:24:50 <AndersonQuach> SteveSouders: as the page is loading we'll be adding things to the resource timing array, and incrementing a counter. it would be better just to add things on the array and get the length. i'll flip here, there's a chance that this attribute has decreased value, redundant with resource timing. there is a little bit of complexity slowing down getting navigation timing out.
16:25:11 <AndersonQuach> SteveSouders: i'm fine with omitting resourceCount from navigation timing.
16:25:40 <AndersonQuach> Zhiheng: in addition to what we have in resource timing, we can expose a counter to make it easy to get a resource count.
16:27:11 <AndersonQuach> NicJansma: resourceCount / requestCount is a close fit to the length of ResourceTiming; what do you think about uniqueDomains, they can compute the # uniqueDomains on their own, it would be nice to provide that to them. is this something we can fit into navigation timing.
16:27:33 <AndersonQuach> SteveSouders: recommend bundle them together and post-pone them until resource timing.
16:28:26 <AndersonQuach> AndersonQuach: sounds like a plan, IE will update the RC to reflect the most stable version of the navigation timing
16:28:37 <AndersonQuach> Tony: will we see window.performance or window.msPerformance
16:28:59 <AndersonQuach> NicJansma: our goal is to have window.performance, as long as we get navigation timing to a stable point.
16:29:33 <AndersonQuach> AndersonQuach: get to CR to drop the vendor prefix
16:29:46 <AndersonQuach> Tony: what are the blockers? 
16:30:09 <AndersonQuach> NicJansma: major differences are uniqueDomains, requestCount, definition of requestEnd
16:31:30 <AndersonQuach> AndersonQuach: work through the differences, stablize the interface and address the definitions in the spec to get the spec stable.
16:31:48 <AndersonQuach> Tony: let's proceed without uniqueDomains and requestCount
16:31:59 <AndersonQuach> Zhiheng: let's move requestCount and uniqueDomains to resource timing
16:32:03 <AndersonQuach> NicJansma: sounds good
16:32:08 <AndersonQuach> next agendum
16:32:26 <AndersonQuach> Zhiheng: get as much information out of the timeline as much as possible.
16:33:03 <AndersonQuach> Zhiheng: that seems like some problem in the implementation, do we need responseStart if the definition of requestEnd be the first byte of the server.
16:33:46 <AndersonQuach> NicJansma: the thoughts in IE, having start and end defined, ease communication. it would be weird to have requestStart, requestEnd and responseEnd.
16:34:55 <AndersonQuach> NicJansma: we have start and stop for everything else, we don't have a stop for fetchEnd or navigationEnd, other phases have very similar timestamps. the time for the end of domain name lookup is close / similar to establishing the connection. it does not add a lot of overhead in the browser. it does help communicate the overall picture. it will help the developer understand the navigation.
16:35:48 <AndersonQuach> Tony: what are your thoughts on measures and marks in IE?
16:36:07 <AndersonQuach> AndersonQuach: in IE we will either vendor prefix or drop them for RTW.
16:36:30 <AndersonQuach> Tony: we are leaning the way not having measures, i can echo what Nic says, it's nice for the developers, it looks like a measure, but you have to do the subtraction.
16:36:46 <AndersonQuach> NicJansma: you can layout the overall timeline with start-stop marks.
16:37:10 <AndersonQuach> NicJansma: having the full timeline from the marks will make it more intuitive.
16:38:01 <AndersonQuach> NicJansma: we added it to the IE9 platform preview for feedback, but we have not gotten a lot of feedback from the community about this interface. if we decided to keep the measures, it may take longer to get through the navigation timing spec.
16:38:20 <AndersonQuach> NicJansma: we put it in because we thought it would be easy to use and useful for site developers.
16:38:31 <AndersonQuach> SteveSouders: what's the definition to measures?
16:39:21 <AndersonQuach> NicJansma: measures are the subtraction of the timing phases defined in the marks. e.g. dns measure is domainLookupEnd - domainLookupStart. easy to pack and easy to JSON.stringify
16:39:38 <AndersonQuach> NicJansma: it only gives you the deltas of the phases not the full details of the utc timestamps.
16:40:08 <AndersonQuach> Zhiheng: seems like can omit in the measures for now and add the responseStart
16:40:45 <AndersonQuach> NicJansma: that's my thoughts
16:41:11 <AndersonQuach> AndersonQuach: as long as we can get to a uniform definition that is interopable to get a stable spec.
16:42:05 <AndersonQuach> Tony: i like easily packable, i don't like redundant information. this is a grey close call. if all the users want to JSON.stringify to send it home. at this point, i really want to get to requestEnd, if marks in general should look like measures. wondering if starts and end should match up.
16:42:52 <AndersonQuach> NicJansma: as a best practice, provide a JSON library to pack up the timing measures that's in a tightly packed structure, we can provide this type of sample to the community, here's 20-30 lines of JScript that makes this JSON array in a measure in a defined order.
16:43:12 <AndersonQuach> NicJansma: measure is redundant data.
16:43:50 <AndersonQuach> Tony: Browser done its job to expose information that did not exist before, we do not yet what exactly is useful and we don't know what will be useful in the future. leaving measures up to the app is appealing to me.
16:44:07 <AndersonQuach> NicJansma: we can always revisit measures in a future interface. 
16:44:16 <AndersonQuach> Zhiheng: we have an agreement here.
16:44:36 <AndersonQuach> Tony: Are you okay with changing the definition of requestEnd == responseStart.
16:44:45 <AndersonQuach> Zhiheng: if everyone agrees let's do it.
16:44:50 <AndersonQuach> Tony: awesome.
16:45:03 <AndersonQuach> NicJansma: we will work to get IE9 to get 100% conforming.
16:45:08 <AndersonQuach> Tony: starting to feel real.
16:45:11 <AndersonQuach> next agendum
16:45:37 <AndersonQuach> Tony: not sure what you mean about that? if you get a reference to the frame, does the underlying object change?
16:48:01 <AndersonQuach> NicJansma: good question, our testers pointed out. clicking a link and directs you to another page, the current page has the navigation timing object and initiating a new navigation. there is two navigation timing objects instantiated. in IE unload the last page only after we downloaded the new page, in the unload JavaScript even there is two navigation timings. the lifetime was not defined for the unload event. unload cannot pop-up dialog, cannot guar
16:48:18 <AndersonQuach> Tony: they can make an img request 
16:48:53 <AndersonQuach> NicJansma: we do not make guarrantee packaging and transmission of navigation timing in unload, recommend to do it in onBeforeUnload.
16:49:02 <AndersonQuach> NicJansma: get your feedback on the lifetime.
16:49:19 <AndersonQuach> Tony: in unload the current page performance information is available.
16:49:31 <AndersonQuach> Tony: it would be strange to expose information for subsequent page.
16:49:39 <AndersonQuach> NicJansma: we don't want to do that's the wrong thing.
16:50:01 <AndersonQuach> Tony: everything accessible in beforeunload is accessible in unload. that's the way i implemented the webkit version.
16:50:10 <AndersonQuach> Tony: is that difficult in IE?
16:50:29 <AndersonQuach> NicJansma: there are technical challenges, but not a driving factor to what we want it to be.
16:51:00 <AndersonQuach> Tony: if developers should not be doing much in the unload handler, they will try to ping this information back in the unload handler. i expect web developers to expect this to work.
16:51:21 <AndersonQuach> NicJansma: one option is to access denying object in unload event.
16:52:00 <AndersonQuach> Tony: i don't know how big the technical objects. webkit, everything is ref counted. if it's really hard. i would not be opposed to exploring other options. however, it should be accessible.
16:52:19 <AndersonQuach> Zhiheng: is there anything blocking to releasing the navigation object in unload.
16:52:53 <AndersonQuach> NicJansma: currently in the IE9 beta, future timing is started to be exposed in unload event, this can be worked around. we wanted to define the lifetime.
16:53:21 <AndersonQuach> Zhiheng: we should keep the current browsing context in unload before populating the target / next browsing context in unload.
16:54:18 <AndersonQuach> AndersonQuach: need to provide a constraint that the timing is relevant for the current browsing context in all events
16:54:48 <AndersonQuach> Zhiheng: if i have JScript getting the timing object in the unload, what timing object are we getting.
16:55:18 <AndersonQuach> Tony: in the current page, webkit has two timing objects in unload. the target navigation's timing object is not accessible in the current page's unload.
16:56:08 <AndersonQuach> Tony: look for any property in the window object, language or pattern to indicate properties of window object should have
16:56:13 <AndersonQuach> Zhiheng: i'll check it out
16:56:22 <AndersonQuach> AndersonQuach: sounds like a good plan
16:56:30 <AndersonQuach> list the agenda
16:56:46 <AndersonQuach> Zhiheng: good shape
16:56:54 <AndersonQuach> Tony: we solved the first three we have consens
16:57:27 <AndersonQuach> agenda 12
16:57:50 <AndersonQuach> move to agendum 12
16:58:56 <AndersonQuach> AndersonQuach: i'd like to propose review navigation timing, and review the intended reference implementation in IE9 and in Webkit, thoughts?
16:59:26 <AndersonQuach> SteveSouders: those sound good to me. focusing on things that are better face to face than over email. 
17:00:06 <AndersonQuach> SteveSouders: we can work on examples, we may have a 30 line snippet for javascript, use the timing and becon it back. work on recommended sample snippets. may iterate faster live. add code samples.
17:00:12 <AndersonQuach> AndersonQuach: agreed
17:00:26 <AndersonQuach> Tony: great time to draw a straw man for the resource timing and user timing.
17:01:03 <AndersonQuach> AndersonQuach: can use the time to dive deeper in ResourceTiming.
17:01:16 <AndersonQuach> Zhiheng: let's bring up these issues in the face to face meeting.
17:01:33 <AndersonQuach> NicJansma: do we want to tackle user timing in the f2f or the next conference call. 
17:02:02 <AndersonQuach> SteveSouders: let's talk about it on the conference call a little bit. i would add both of those tenatively to the agenda for the f2f. we should figure out which is more important.
17:02:12 <AndersonQuach> NicJansma: sounds good let's talk about it next week's conference call.
17:02:33 <AndersonQuach> Zhiheng: if we can come up with the initial draft of user timing before the face to face.
17:02:41 <AndersonQuach> AndersonQuach: i'll sign up for that. 
17:02:56 <Zakim> - +1.650.823.aaaa
17:02:56 <AndersonQuach> move to agenda 13
17:02:59 <Zakim> - +1.650.214.aabb
17:03:02 <Zakim> -[Microsoft]
17:03:08 <Zakim> -Zhiheng
17:03:09 <Zakim> RWC_web-per(WPWG)12:00PM has ended
17:03:10 <AndersonQuach> NicJansma: additional business?
17:03:11 <Zakim> Attendees were [Microsoft], Zhiheng, +1.650.823.aaaa, +1.650.214.aabb
17:03:17 <AndersonQuach> Zhiheng: sounds good.
17:04:02 <AndersonQuach> rrsagent, draft minutes
17:04:02 <RRSAgent> I have made the request to generate http://www.w3.org/2010/09/22-webperf-minutes.html AndersonQuach
17:04:42 <AndersonQuach> rrsagent, format minutes
17:04:42 <RRSAgent> I have made the request to generate http://www.w3.org/2010/09/22-webperf-minutes.html AndersonQuach
17:04:52 <AndersonQuach> rrsagent, generate minutes
17:04:52 <RRSAgent> I have made the request to generate http://www.w3.org/2010/09/22-webperf-minutes.html AndersonQuach
17:05:01 <AndersonQuach> rrsagent, make minutes
17:05:01 <RRSAgent> I have made the request to generate http://www.w3.org/2010/09/22-webperf-minutes.html AndersonQuach
17:05:08 <AndersonQuach> rrsagent, publish minutes
17:05:08 <RRSAgent> I have made the request to generate http://www.w3.org/2010/09/22-webperf-minutes.html AndersonQuach
17:05:27 <NicJansma> NicJansma has left #webperf