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.h&sq=package:chromium&type=cs&rcl=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.cc&sq=package:chromium&type=cs&rcl=1411964872&l=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
