- From: Arvind Jain <arvind@google.com>
- Date: Wed, 4 Sep 2013 11:31:45 -0700
- To: William Chan (陈智昌) <willchan@chromium.org>
- Cc: Jatinder Mann <jmann@microsoft.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>
- Message-ID: <CAOYaDdMWELFpkgsrYP7=BS4pAfjw8pQAFD1LSsKh9ZuzSkVyBw@mail.gmail.com>
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