16:58:04 <RRSAgent> RRSAgent has joined #webperf
16:58:04 <RRSAgent> logging to http://www.w3.org/2012/05/16-webperf-irc
16:58:06 <trackbot> RRSAgent, make logs world
16:58:06 <Zakim> Zakim has joined #webperf
16:58:08 <trackbot> Zakim, this will be WPWG
16:58:09 <trackbot> Meeting: Web Performance Working Group Teleconference
16:58:09 <trackbot> Date: 16 May 2012
16:58:09 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
16:58:21 <JatinderMann> present+ JatinderMann
16:58:25 <JatinderMann> present+ Alois
16:58:36 <Sigbjorn_> Sigbjorn_ has joined #webperf
17:01:49 <tonyg> tonyg has joined #webperf
17:02:51 <JatinderMann> present+ Sigbjorn
17:02:56 <JatinderMann> present+ tonyg
17:05:14 <markw> markw has joined #webperf
17:06:18 <JatinderMann> Topic: Media Timing
17:06:47 <JatinderMann> Jatinder: We have Mark from Netflix here today to discuss audio and video requirements for a performance metric.
17:09:18 <JatinderMann> Mark: We wanted the JavaScript aspect to determine the throughput rate of video and audio elements, so we can make decisions and update the user experience. We saw what you have in Resource Timing and we noticed that it covers both the video element and XHRs. Two things I noticed were we use for adaptive streaming is byte range request, which in itself is a http request and we would like to see that data captured, and the progress of the request, so if 
17:09:22 <JatinderMann> ... the data arrives.
17:10:10 <JatinderMann> Arvind: One of the fundamental differences is today Resource Timing is made available once the entire resource has been downloaded. Seems like you are asking for a progress indicator.
17:10:19 <JatinderMann> Mark: Yes, I think that's a part of it.
17:11:49 <JatinderMann> Arvind: I think this would require a significant change to the Resource Timing spec. Let me understand the use case, as chucks of the video is getting downloaded, you will make a decision and change the bitrate. Can't you do this already using the media source API? You would make a XHR request and then you would see when it comes back...
17:16:46 <JatinderMann> Arvind: Do we support XHRs in Resource Timing? 
17:16:49 <JatinderMann> Jatinder: Yes
17:17:05 <JatinderMann> Arvind: We should have a XHR for every AJAX call we would make? I would expect that it would. It would include the range request
17:19:04 <JatinderMann> Mark: It seems like the name attribute is the unique identifier. For XHRs, we would want the URL and byte range together as the name attribute?
17:19:48 <JatinderMann> Mark: The range request would seem like the basic data that you need.
17:20:05 <JatinderMann> Karen: We haven't discussed partial responses. We may want to include that as well?
17:21:04 <JatinderMann> Mark: We may want to include the header data, but you may open a can of worms from a privacy point of view.
17:21:42 <JatinderMann> Arvind: With the resource timing, you will also see multiple resource timing objects for each chunk.
17:24:45 <JatinderMann> Arvind: Quite a few issues. Let's talk about them one at a time. The first is that for multiple ajax xhr calls, you will get multiple resource objects. We may want to include http headers into the resource timing. However, there were issues with that?
17:25:04 <JatinderMann> Tony: Yes, there could be privacy / fingerprinting issues with keeping that data around.
17:25:18 <JatinderMann> Karen: We should think about this in more detail before closing on it.
17:25:34 <JatinderMann> Arvind: Agree, let's chat more about this and close on it in the future.
17:26:45 <JatinderMann> Mark: If you had an event that would fire when each resource timing object was added, so you can determine which resource corresponds to which byte range. We can do this without giving the header information.
17:27:12 <JatinderMann> Alois: Is the goal really to determine the bandwidth so you can make decisions? Shouldn't we focus on how to get that data.
17:28:44 <JatinderMann> Mark: I would recommend providing JavaScript with as much information happening on the lower level network so it can make decisions. Seems like you have provided most of the low level information. One information missing seems like the byte arrival of data. You can imagine providing a property that would let you know how many bytes have arrived so far.
17:29:45 <JatinderMann> Mark: I will have to go right now, however, I can join in another future call to discuss some more. 
17:31:50 <JatinderMann> Tony: There's also one point that we should clarify is that this is after the fact analysis. It was never designed to provide real time progress data, UAs can add the data at anytime they wish, not real time. 
17:32:40 <JatinderMann> Jatinder: I also agree that these APIs were designed for post processing analysis. Shouldn't the elements they are trying to download be extended to provide this type of progress data?
17:33:03 <JatinderMann> Arvind: We should talk about this more next week. Besides the progress issue, there is also the naming issues.
17:33:40 <JatinderMann> Arvind: The naming issue of XHRs seems like an immediate issue that we need to address in the Resource Timing.
17:35:14 <JatinderMann> Arvind: For things where we have multiple downloads for the same entity, the API already provides all the data, we should determine if we want to distinguish between them. Let's chat about them next week.
17:35:44 <JatinderMann> Arvind: Seems like we have two issues: progress indication and distinguishing between multiple chunks.
17:36:57 <JatinderMann> Sigbjorn: What would we do for a native video element?
17:40:37 <JatinderMann> Arvind: We should be give a single resource, I believe.
17:40:57 <JatinderMann> Jatinder: What about when the video isn't auto-playing? What about a seek?
17:41:10 <JatinderMann> Jatinder: What does the dev tools do today?
17:41:31 <JatinderMann> Arvind: I believe its a single element (one line item) instead of multiple items.
17:42:24 <JatinderMann> Tony: I think we need to determine whether we should treat it as a single element or have multiple http requests.
17:42:54 <JatinderMann> Issue Determine how audio, video and embed elements appear in the timeline
17:43:53 <JatinderMann> Action Determine how audio, video and embed elements appear in the timeline
17:43:53 <trackbot> Sorry, couldn't find user - Determine
17:43:59 <JatinderMann> Action Jatinder Determine how audio, video and embed elements appear in the timeline
17:43:59 <trackbot> Created ACTION-104 - Determine how audio, video and embed elements appear in the timeline [on Jatinder Mann - due 2012-05-23].
17:44:05 <JatinderMann> Topic: Navigation Timing
17:47:07 <JatinderMann> Jatinder: As three browsers have implemented this API and two have them unprefixed, customers have started to use, and the API is useful and meets the goals it set out for, and UAs will not remove this API, we want to keep this spec to document the behavior and keep the test cases to ensure interoperability.
17:49:58 <JatinderMann> Tony: I do not want to pull out the current Navigation Timing, as vendors have unprefixed it and we want to continue to ensure the spec is standarized.
17:51:52 <JatinderMann> Arvind: In our last discussion, two weeks back, we agreed that the Navigation Timing 2 should state that Navigation Timing 1 should be implemented. If that is the case, we should standarize Navigation Timing.
17:53:18 <JatinderMann> Alois: As a developer, we would check the new API and the old API, so we would use both of them.
17:54:23 <JatinderMann> Arvind: If our goal is to have all browsers to implement the old API, then we should standarize the spec.
18:25:18 <JatinderMann> Arvind: We should get Philippe's opinion on this matter as well.
18:25:52 <JatinderMann> Jatinder: Considering Philippe will be back in a month and we aren't planning on moving the spec to PR until that point, we should close on this discussion at that point.
18:26:04 <JatinderMann> rrsagent, generate minutes
18:26:04 <RRSAgent> I have made the request to generate http://www.w3.org/2012/05/16-webperf-minutes.html JatinderMann