W3C home > Mailing lists > Public > public-web-perf@w3.org > September 2013

Re: [minutes] Web Performance WG Teleconference #118 2013-09-04

From: Arvind Jain <arvind@google.com>
Date: Wed, 4 Sep 2013 11:31:45 -0700
Message-ID: <CAOYaDdMWELFpkgsrYP7=BS4pAfjw8pQAFD1LSsKh9ZuzSkVyBw@mail.gmail.com>
To: William Chan (陈智昌) <willchan@chromium.org>
Cc: Jatinder Mann <jmann@microsoft.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>
Is there a method to fetch the protocol from Javascript?

Arvind


On Wed, Sep 4, 2013 at 11:19 AM, William Chan (陈智昌)
<willchan@chromium.org>wrote:

> I'm excited to see folks have agreed to include the wire protocol. While
> non-standard protocols like SPDY may not be included in the spec, is it
> reasonable to write the spec in such a way to allow implementers to include
> whatever string they want? Here are the use cases I'd like considered:
> * As we work on HTTP/2, I'd like to be able to compare performance when
> using different draft versions. We often do this in Chrome by running A/B
> tests. This is useful for advising the HTTP/2 standardization process when
> debating features.
> * Similarly to the above, we'd like to experiment with new protocols (e.g.
> QUIC) and compare them to raw HTTP over TCP.
>
> That said, I also see value in only having standard tokens reported for
> the wire protocol. I just wanted to point out that there are some use cases
> we'd like to support if possible, so it'd be cool if you could consider
> them :)
>
> Cheers.
>
>
> On Thu, Sep 5, 2013 at 2:09 AM, Jatinder Mann <jmann@microsoft.com> wrote:
>
>>  *Meeting Summary:*****
>>
>>  ****
>>
>> **1.     ***Wire Protocol Information*****
>>
>> Seeing that progress is being made on HTTP2.0, the working group feels
>> that Navigation Timing L2 and Resource Timing L2 should at least indicate
>> the wire protocol information, e.g., "http/1.0", "http/1.1", "http/2.0". We
>> need to determine whether other metrics around wire protocol should be
>> exposed as well. We will setup another conference call to specifically
>> discuss this point, inviting all interested members.****
>>
>> ** **
>>
>> **2.     ***User Timing - Closures*****
>>
>> The working group needs to consider whether we want to take a change to
>> User Timing to address the issue raised here:
>> http://lists.w3.org/Archives/Public/public-web-perf/2013Jun/0001.html. **
>> **
>>
>> ** **
>>
>> **3.     ***TPAC 2013 Agenda*****
>>
>> Based on the conference call discussion, the TPAC agenda has been amended
>> to include time for HAR and Async Scrolling, and limit the public
>> performance discussion to Thursday evening. ****
>>
>> ** **
>>
>> *Thursday, November 14, 2013*
>>
>> 09:00 AM - 09:30 AM:    Introductions****
>>
>> 09:30 AM - 10:00 AM:    Prerender Discussion****
>>
>> 10:00 AM - 11:00 AM:    Beacon Discussion****
>>
>> 11:00 AM - 12:00 PM:    Resource Priorities Discussion****
>>
>> 12:00 PM - 01:00 PM:    Lunch****
>>
>> 01:00 PM - 02:00 PM:    Element Visibility and Page Visibility L2
>> Discussion****
>>
>> 02:00 PM - 02:30 PM:    High Resolution Time L2 Discussion****
>>
>> 02:30 PM - 04:00 PM:    HTML5 Working Group visit****
>>
>> 04:00 PM - 05:00 PM:    Break****
>>
>> 05:00 PM - 07:00 PM:    Performance Workshop (Open to non-members)****
>>
>> ** **
>>
>> *Friday, November 15, 2013*
>>
>> 09:00 AM - 10:30 AM:    Timing API Discussion****
>>
>> 10:30 AM - 11:30 AM:    Navigation and Resource Error Logging Discussion*
>> ***
>>
>> 11:30 AM - 12:00 PM:    JavaScript Injection Discussion****
>>
>> 12:00 PM - 01:00 PM:    Lunch****
>>
>> 01:00 PM - 02:00 PM:    Display Paint Notifications Discussion****
>>
>> 02:00 PM - 03:00 PM:    Efficient Script Yielding Discussion****
>>
>> 03:00 PM - 04:00 PM:    HAR and Async Scroll Discussion****
>>
>> 04:00 PM - 05:00 PM:    Discuss Potential New Specifications****
>>
>> ** **
>>
>> **4.     ***Next Conference Call Time Slot*****
>>
>> To accommodate members in Asia and New Zealand, the working group is
>> proposing meeting on Wednesdays at 12PM PST, which will be 9PM in Europe,
>> and 7AM in Asia and New Zealand. If there are no objections to this
>> proposal, we will update the meeting time for the next conference call.**
>> **
>>
>> ** **
>>
>>  ****
>>
>> *W3C Web Performance WG Teleconference #11**8 2013-09-04*****
>>
>> ** **
>>
>> ** **
>>
>> *IRC log:* http://www.w3.org/2013/09/04-webperf-irc ****
>>
>>  ****
>>
>> *Meeting Minutes:* http://www.w3.org/2013/09/04-webperf-minutes.html ****
>>
>>  ****
>>
>> *Attendees*****
>>
>> Jatinder Mann, Philippe Le Hegaret, Alois Reitbauer, Dan Austin, James
>> Simonsen, Rob Dickenson, Ganesh Rao, Aaron Heady****
>>
>>  ****
>>
>> *Scribe *****
>>
>> Jatinder Mann****
>>
>>  ****
>>
>> *Agenda*****
>>
>> **1.     **Resource Timing****
>>
>> **2.     **User Timing****
>>
>> **3.     **TPAC Agenda****
>>
>> **4.     **Conference Call Time****
>>
>> **5.     **Tests****
>>
>>
>>
>> --------------------------------------------------------------------------------
>> ****
>>
>> ** **
>>
>> *Minutes:*
>>
>> *Resource Timing***
>>
>> http://lists.w3.org/Archives/Public/public-web-perf/2013Sep/0002.html****
>>
>> *Jatinder:* Since we have SPDY implementations in all browsers, seems
>> reasonable to add protocol information in Resource Timing L2.****
>>
>> <*plh*> enum ProtocolString { "http/1.0", "http/1.1", "http/2.0" }; ?****
>>
>> *Daniel:* There is value in adding protocol information. What are we
>> going to call it? Just the version number or the entire string?****
>>
>> *Jatinder:* Do we want to share SPDY or just HTTP?****
>>
>> *Daniel:* We shouldn't share proprietary protocols in my opinion. We
>> should stick with HTTP only.****
>>
>> *Plh:* In the long run, it should be HTTP anyway.****
>>
>> *Alois:* As developers, its reasonable to know exactly what the exact
>> string is.****
>>
>> *Ganesh:* Is this another attribute like initiatorType?****
>>
>> *Jatinder:* Yes, it would be a new attribute like initiatorType, we
>> should probably call it wireProtocol or protocol. It would be an enum.***
>> *
>>
>> http://lists.w3.org/Archives/Public/public-web-perf/2013Sep/0002.html****
>>
>> *Jatinder:* We should also add this for Navigation Timing L2?****
>>
>> *Daniel:* Yes.****
>>
>> *Plh:* Yes.****
>>
>> <*Alois*> Yes.****
>>
>> *Plh:* If I recall, HTTP2.0 requires SSL.****
>>
>> *Daniel:* If I recall, we should also add SSLConnectEnd and make
>> SSLConnectStart not optional.****
>>
>> *Plh:* If I recall, we made SSLConnectStart optional because of IE.****
>>
>> *Jatinder:* I'm not sure why its optional. I can check if there is a
>> technical reason in IE, but I don't think it should be optional, especially
>> if SSL is required for HTTP2.0****
>>
>> *James:* Its not clear if SSLConnectEnd is any different from
>> connectionStart. We should follow up and confirm.****
>>
>> *Alois:* We may want to add more metrics for protocol, especially
>> details on whether it is chuck encoded.****
>>
>> *Jatinder:* I think we should Mark on the call next week and discuss.****
>>
>> *User Timing*
>>
>> http://lists.w3.org/Archives/Public/public-web-perf/2013Jun/0001.html****
>>
>> *James:* Seems like a nice way to solve this.****
>>
>> *Jatinder:* I haven't finished reading it. I'll take a look at it.****
>>
>> *Plh:* Are we going to break deployed code?****
>>
>> *Jatinder:* We should check. If there are, we should re-consider.****
>>
>> *James:* Agree.****
>>
>> *Jatinder:* On the topic of L2 specs, are we doing delta specs instead
>> of a full re-definition? I prefer deltas, since it makes it very clear what
>> is different.****
>>
>> *James:* I would prefer that as well.****
>>
>> *Plh:* There are two schools of thoughts. But whatever the editor
>> decides.****
>>
>> *TPAC Agenda*
>>
>> http://lists.w3.org/Archives/Public/public-web-perf/2013Sep/0004.html****
>>
>> *Plh:* We may want to be more specific with how much time we want to
>> spend with HTML5.****
>>
>> *Jatinder:* Right now we only have prerender, but we will know better
>> soon. I think we should be more specific.****
>>
>> *Plh:* We should also add time for HAR and Async Scroll.****
>>
>> *Jatinder:* I don't think we need a second Performance Workshop on
>> Friday. We should spent that time on HAR and Async Scrolling, but also an
>> open hour for possibly new specs that come out of Thursday's discussion.*
>> ***
>>
>> <*plh*> noon PT/3pm ET/9pm CET****
>>
>> *New Conference Call*
>>
>> *Jatinder:* To help our members in New Zealand and Asia join the calls,
>> we should move the conference call time to 12PM PST, which is 9PM in
>> Europe, and 7AM in New Zealand. Does that work for everyone?****
>>
>> *Alois:* Works for me.****
>>
>> *James:* For me as well.****
>>
>> *Jatinder:* Looks like it works for all. I'll send email on it.****
>>
>> *Tests*
>>
>> *Plh:* I am almost done moving all the test cases to the new repository.
>> I'll send details next week.****
>>
>> *Jatinder:* I still need to review the Resource Timing test cases. Are
>> there any known issues?****
>>
>> *Plh:* Some tests (x-origin tests) haven't been migrated correctly to
>> the right server.****
>>
>> *James:* The initatorType test doesn't work as well currently.****
>>
>> *Jatinder:* I'll review the rest.****
>>
>> * *
>>
>
>
Received on Wednesday, 4 September 2013 18:32:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:01:20 UTC