Re: PFWG request for abstract and introductions
On 9/4/14 8:51 AM, Arthur Barstow wrote: Hi Michael, All, Thanks for your e-mail. I'm _really_ sorry for the delayed reply [this email was accidentally moved to my Back Burner folder where I just noticed it)! Although I will check all of WebApps' specs and ask Editors to update their documents accordingly, are there any specs that are of high/keen interest to you? (WebApps' spec list is https://www.w3.org/2008/webapps/wiki/PubStatus.) Hi Michael, All, Yves and Cindy agreed to take the lead to followup on your request. My expectation is they will check all of WebApps' specs and if/when a spec could be improved, they will file a Bug/Issue accordingly. Again, if you and/or your colleagues have specific specs that concern you, please do let us know. -Thanks, Art On 6/20/14 10:33 AM, Michael Cooper wrote: The WAI Protocols and Formats Working Group has looked at a number of specifications published by the Web Applications Working Group recently. Our process is to note the publication of documents and take a quick look to determine if they need a closer review. However, many of the documents we have looked at recently have extremely brief abstracts, and no introductions. This makes it very difficult for us to figure out the nature of the specification, and in turn to determine what our interest in it might be. We request that you add more complete abstracts to the specifications, to provide a high-level but more complete idea of what the specification does. We also request that you add introduction sections to the specifications, to explain what problem the technology solves and how (in general terms) it addresses that. We think this will aid our own review and will also greatly help other reviewers to make useful comments. Michael Cooper PFWG staff contact
=[xhr] Expose XMLHttpRequest priority
Hi all, I would like to see a priority field added to XMLHttpRequest. Mike Belshe's proposal here is a great start: http://www.mail-archive.com/public-webapps@w3.org/msg08218.html *Motivation* Browsers already prioritize network requests. By giving XMLHttpRequest access to the same machinery, the page or application can reduce overall latency and make better use of available bandwidth. I wrote about our specific use case (efficiently streaming hundreds of 3D assets into WebGL) in detail at http://chadaustin.me/2014/08/web-platform-limitations-xmlhttprequest-priority/ Gecko appears to support a general 32-bit priority: http://lxr.mozilla.org/mozilla-central/source/xpcom/threads/nsISupportsPriority.idl and http://lxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/HttpBaseChannel.cpp#45 Chrome appears to be limited to five priorities: https://code.google.com/p/chromium/codesearch#chromium/src/net/base/request_priority.hsq=package:chromiumtype=csrcl=1411964872 but seems to have a fairly general priority queue implementation. https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/loader/resource_scheduler.ccsq=package:chromiumtype=csrcl=1411964872l=206 SPDY exposes 3 bits of priority per stream. *Proposal* Add a numeric priority property to XMLHttpRequest. It is a 3-bit integer from 0 to 7. Default to 3. 0 is most important. Why integers and not strings, as others have proposed? Because priority arithmetic is convenient. For example, in our use case, we might say The top bit is set by whether an asset is high-resolution or low-resolution. Low-resolution assets would be loaded first. The bottom two bits are used to group request priorities by object. The 3D scene might be the most important resource, followed by my avatar, followed by closer objects, followed by farther objects. Note that, with a very simple use case, we've just consumed all three bits. There's some vague argument that having fewer priorities makes implementing prioritization easier, but as we've seen, the browsers just have a priority queue anyway. Allow priorities to change after send() is called. The browser may ignore this change. It could also ignore the priority property entirely. I propose XMLHttpRequest priority not be artificially limited to a range of priorities relative to other resources the browser might initiate. That is, the API should expose the full set of priorities the browser supports. If my application wants to prioritize an XHR over some browser-initiated request, it should be allowed to do so. The more control over priority available, the better a customer experience can be built. For example, at the logical extreme, fine-grained priority levels and mutable priority values would allow dynamically streaming and reprioritizing texture mip levels as objects approach the camera. If there's enough precision, the application could set priority of an object to the distance from the camera. Or, in a non-WebGL scenario, an image load's priority could be set to the distance from the current viewport. I believe this proposal is very easy to implement: just plumb the priority value through to the prioritizing network layer browsers already implement. What will it take to get this added to the spec? Thanks, -- Chad Austin Technical Director, IMVU http://chadaustin.me
Re: =[xhr] Expose XMLHttpRequest priority
On Tue, Sep 30, 2014 at 10:25 AM, Chad Austin caus...@gmail.com wrote: What will it take to get this added to the spec? There's been a pretty long debate on the WHATWG mailing list how to prioritize fetches of all things. I recommend contributing there. I don't think we should focus on just XMLHttpRequest. -- https://annevankesteren.nl/
Re: =[xhr] Expose XMLHttpRequest priority
On Tue, Sep 30, 2014 at 5:28 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Sep 30, 2014 at 10:25 AM, Chad Austin caus...@gmail.com wrote: What will it take to get this added to the spec? There's been a pretty long debate on the WHATWG mailing list how to prioritize fetches of all things. I recommend contributing there. I don't think we should focus on just XMLHttpRequest. Hi Anne, Thanks for the quick response. Is this something along the lines of a SupportsPriority interface that XHR, various DOM nodes, and such would implement? Can you point me to the existing discussion so I have context? Thanks, Chad
Re: =[xhr] Expose XMLHttpRequest priority
http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Aug/0081.html - I recently got some good offline feedback on the proposal, need to update it, stay tuned. http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Aug/0177.html - related~ish, may be of interest. ig On Tue, Sep 30, 2014 at 9:39 AM, Chad Austin caus...@gmail.com wrote: On Tue, Sep 30, 2014 at 5:28 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Sep 30, 2014 at 10:25 AM, Chad Austin caus...@gmail.com wrote: What will it take to get this added to the spec? There's been a pretty long debate on the WHATWG mailing list how to prioritize fetches of all things. I recommend contributing there. I don't think we should focus on just XMLHttpRequest. Hi Anne, Thanks for the quick response. Is this something along the lines of a SupportsPriority interface that XHR, various DOM nodes, and such would implement? Can you point me to the existing discussion so I have context? Thanks, Chad
Re: IndieUI Teleconference Agenda; 1 October at 21:00Z for 60 minutes
Regrets. We’ll be signing mortgage paperwork at this time. On Sep 30, 2014, at 3:22 PM, Janina Sajka jan...@rednote.net wrote: Cross-posting as before ... What:IndieUI Task Force Teleconference When:Wednesday 1 October 2:00 PMSan Francisco -- U.S. Pacific (Daylight) Time (PDT: UTC -7) 4:00 PMAustin -- U.S. Central (Daylight) Time (CDT: UTC -5) 5:00 PMBoston -- U.S. Eastern (Daylight) Time (EDT: UTC -4) 10:00 PMLondon -- British (Summer) Time (BST: UTC +1) 11:00 PMParis -- Central European Time (CET: UTC +2) 5:00 AMBeijing -- China Standard Time (Thursday, 2 October CST: UTC +8) 6:00 AMTokyo -- Japan Standard Time (Thursday, 2 October JST: UTC +9) Where:W3C Teleconference--See Below * Time of day conversions Please verify the correct time of this meeting in your time zone using the Fixed Time Clock at: http://timeanddate.com/worldclock/fixedtime.html?msg=IndieUI+Teleconferenceiso=20141001T1700p1=43ah=1 ** Preliminary Agenda for IndieUI Task Force Teleconference 1 October 2014 Meeting: IndieUI Task Force Teleconference Chair:Janina_Sajka agenda+ preview agenda with items from two minutes agenda+ Editor's Report agenda+Clipboard API http://www.w3.org/standards/history/clipboard-apis agenda+Checkin with Web Apps' Editing TF [See below] agenda+Testing Conversation; Polyfills agenda+Requirements Use Cases Progress agenda+ TPAC Planning http://www.w3.org/2014/11/TPAC/ agenda+ User Context Issues Actions https://www.w3.org/WAI/IndieUI/track/products/3 agenda+ Events Issues Actions https://www.w3.org/WAI/IndieUI/track/products/2 agenda+ Other Business agenda+Be Done Resource: IndieUI Minutes http://www.w3.org/2014/09/17-indie-ui-minutes.html Resource: Web Apps Editing TF Editing Explainer:http://w3c.github.io/editing-explainer/ User Intentions: http://w3c.github.io/editing-explainer/commands-explainer.html Resource: For Reference Home Page:http://www.w3.org/WAI/IndieUI/ Email Archive:http://lists.w3.org/Archives/Public/public-indie-ui/ Resource: Teleconference Logistics Dial the Zakim bridge using either SIP or the PSTN. PSTN: +1.617.761.6200 (This is a U.S. number). SIP: za...@voip.w3.org You should be prompted for a pass code, This is 46343# (INDIE#) Alternatively, bypass the Zakim prompts and SIP directly into our teleconference. SIP: 0046...@voip.w3.org Instructions for connecting using SIP: http://www.w3.org/2006/tools/wiki/Zakim-SIP Place for users to contribute additional VoIP tips. http://www.w3.org/2006/tools/wiki/Zakim-SIP-tips IRC: server: irc.w3.org, channel: #indie-ui. During the conference you can manage your participation with Zakim commands as follows: 61# to mute yourself 60# to unMute yourself 41# to raise your hand (enter speaking queue) 40# to lower your hand (exit speaking queue) The system acknowledges these commands with a rapid, three-tone confirmation. Mobile phone users especially should use the mute function if they don't have a mute function in their phone. But the hand-raising function is a good idea for anyone not using IRC. * IRC access An IRC channel will be available. The server is irc.w3.org, The port number is 6665 (Note this is not the normal default) and The channel is #indie-ui. * Some helpful Scribing and Participation Tips http://www.w3.org/WAI/PF/wiki/Teleconference_cheat_sheet For more on the IRC setup and the robots we use for agenda and speaker queuing and for posting the log to the web, see: - For RRSAgent, that captures and posts the log with special attention to action items: http://www.w3.org/2002/03/RRSAgent - For Zakim, the IRC interface to the bridge manager, that will maintain speaker and agenda queues: http://www.w3.org/2001/12/zakim-irc-bot - For a Web gateway to IRC you can use if your network administrators forbid IRC, see: http://www.w3.org/2001/01/cgi-irc - For more on W3C use of IRC see: http://www.w3.org/Project/IRC/ -- Janina Sajka,Phone:+1.443.300.2200 sip:jan...@asterisk.rednote.net Email:jan...@rednote.net The Linux Foundation Chair, Open Accessibility:http://a11y.org The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI) Chair,Protocols Formatshttp://www.w3.org/wai/pf IndieUIhttp://www.w3.org/WAI/IndieUI/
