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

0-7 priority is not sufficient. See previous discussion / proposal:
http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Aug/0081.html

ig

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:10:48 UTC