=[xhr] Expose XMLHttpRequest priority

2014-09-30 Thread Chad Austin
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

2014-09-30 Thread Anne van Kesteren
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

2014-09-30 Thread Chad Austin
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

2014-09-30 Thread Ilya Grigorik
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