Closed Bug 559092 Opened 14 years ago Closed 2 years ago

Add priorities to XMLHttpRequest


(Core :: DOM: Core & HTML, defect)

Not set





(Reporter: smaug, Assigned: smaug)



(1 file, 1 obsolete file)

There is a proposal to add setPriority to XMLHttpRequest.
I think it makes sense, and would be easy to implement, AFAIK.

I do quickly a prototype implementation and a demo.
nsISupportsPriority in http channels doesn't seem to work quite the
way I was hoping :/
Or perhaps the problem is in my test
and my network connection is pretty fast
Attached patch wip (obsolete) — Splinter Review
Actually, the wip works just fine.

Start ~10 XHR, only 6 of them will start loading immediately.
Then the next ones will start based on priority.
Attached patch wip, v2Splinter Review
By default don't change the priority.
Attachment #438800 - Attachment is obsolete: true
I'm not yet sure whether this all should somehow take account priorities in
different tabs. Should background tab's "CRITICAL" be less critical than
in foreground tab.
Perhaps that kind of thing could be optimized later if needed.
Attachment #438963 - Attachment description: v2 → wip, v2
Cross-linking the WebKit bug:

Hopefully the IDLs will match up.
And because the feature isn't specified properly anywhere, moz and webkit prefixes should be used with constants and method.
I'll upload a new patch with prefixes.
Though, I'm not at all sure what version of the draft spec to implement.
I don't quite like using strings for the priority.

For our WebGL application, we stream down hundreds of individual assets to load a scene.  Some of these assets (skeletons, meshes, low-res textures) are far more important than others (high-res textures).  In addition, some objects in a 3D scene are more important than others.  Your own 3D character is more important than others.  The room is more important than props in the room.

In our native applications, we have the ability to prioritize network traffic appropriately, but on the web, we don't.  Being able to prioritize XMLHttpRequest would be a large improvement to our customer experience.

It sounds like WebSockets might work better for you, and have your own prioritization on top of the
API. That certainly would reduce the overhead of http.
We actually want HTTP so we can leverage CDNs, Varnish, and the browser's cache.  All of our 3D assets are indexed by hash and thus infinitely cacheable, so, while pushing data with WebSockets might be an improvement on the initial load, it doesn't help at all for subsequent loads.

HTTP + priority would be perfect for this use case.
I wrote a blog post describing the use case and poor customer experience that results from not having a priority hint:
Component: DOM → DOM: Core & HTML

There is a proposal now to add priority to fetch() and to element which do resource loading. But XHR won't have it, since it is a bit legacy API.

Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.