Re: [whatwg] Expose XMLHttpRequest [Fetch?] priority

For streaming video, where data is requested block-by-block, it would be
nice to be able to set priority proportional to the time until the
requested video block is needed for rendering. Or at least for relative
priorities between requests to reflect this. I think this means that either
priorities need to be mutable, so I can increase the priority as time
passes and the need for the block becomes more urgent, or I need a large
priority space, so that, for example, I can just give each block a fixed
priority value equal to it's absolute position in the playback sequence.

...Mark

On Wed, Oct 1, 2014 at 10:54 AM, Chad Austin <caustin@gmail.com> wrote:

> Hi all,
>
> I posted the following message to WebApps, but Anne van Kesteren suggested
> that I instead post to WHATWG, and generalize my request to anything that
> supports "Fetch".  When reading below, feel free to interpret
> XMLHttpRequest in the broadest sense.
>
> The proposal follows:
>
> ***
>
> 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, so
> increasing the number of priorities is likely straightforward.
>
> 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?
>
> --
> Chad Austin
> http://chadaustin.me
>

Received on Wednesday, 1 October 2014 18:08:36 UTC