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

All,

FYI ... see below about priorities in XmlHttpRequest. Might be useful for
Cadmium (seems some browsers support something already).

In JS-ASE on NRDP, we are expressing priority through the model of
"download tracks". Each request is prioritized relative to other requests
on the same download track (the priority order is the same order as the
requests are issued), but is not prioritized at all vs requests on other
tracks. This aligns with the NRDP implementation.

An ideal way to specify priority for streaming would be to have a large
number of priority values and give each request the start PTS as its
priority (or zero for headers).

... Mark

---------- Forwarded message ----------
From: Chad Austin <caustin@gmail.com>
Date: Wed, Oct 1, 2014 at 10:54 AM
Subject: [whatwg] Expose XMLHttpRequest [Fetch?] priority
To: whatwg@whatwg.org


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:06:02 UTC