Hi Mike,
FYI,
I wrote a wip patch for Gecko.
https://bugzilla.mozilla.org/show_bug.cgi?id=559092
Test builds will be here:
https://build.mozilla.org/tryserver-builds/opet...@mozilla.com-xhr_priority/
-Olli
On 4/13/10 8:36 PM, Mike Belshe wrote:
On Tue, Apr 13, 2010 at 9:36 AM, Olli Pettay olli.pet...@helsinki.fi
mailto:olli.pet...@helsinki.fi wrote:
Hi,
Thanks for the comments.
this seems like a pretty useful, yet reasonable easily implementable
feature.
Good to hear.
I'd add 5th value NORMAL, which would be the default value.
const unsigned short CRITICAL = 0;
const unsigned short HIGH = 1;
const unsigned short NORMAL = 2
const unsigned short LOW = 3;
const unsigned short LOWEST = 4;
Not sure if we need all the values, or would
HIGH, NORMAL, LOW be enough?
I'm not fussy about what priorities are exposed or what we call them -
so long as they are relatively few in number to avoid unnecessary
complexity. (e.g. 3-5 priority buckets seems fine)
Mike
-Olli
On 4/13/10 7:13 PM, Mike Belshe wrote:
Hi,
I'm a developer on the chrome team, and also working on SPDY.
Others here at Google have requested that we expose some of the
priority-based resource loading mechanics to applications so that
applications can hint to the browser more information about which
resources are critical and which are not. Some of the Google
Apps teams
have already implemented their own, manual priority-based resource
fetchers, and our maps team saw a huge latency reduction as a
result of
doing so. Internally to chromium and webkit, resource loading
is also
priority-aware today. Finally, in SPDY, we've observed good
improvements by exposing priorities all the way across the
protocol. We
believe exposing priority on the XHR object may benefit many
applications manage their resource loads.
Here is a quick writeup of one proposal which we think would work in
browsers. We believe it is backward compatible with existing
XHR, and
can be optionally implemented. It also leaves a fair amount of the
tuning at the discretion of the browser, so it does not create a
long-term liability in the browser. We hope that these
considerations
make it an easy choice to approve.
I'm wondering if the XMLHttpRequest group would be interested in
taking
this on?
Thanks,
Mike
XMLHttpRequest Priority Fetching
Every performant web browser implementation today implements various
heuristics for resource loading prioritization internally. The
notion
is simple, that loading some resources, such as images, are less
performance critical than loading other resources, such as external
style sheets. By implementing basic priorities, browsers achieve
substantially better performance loading web pages. Today,
however, web
applications have no way of giving hints to the browser about
what may
be high or low priority.
Because complex applications heavily rely on resource loading by
way of
XmlHttpRequest, we propose a simple, backward compatible, and
optional
mechanism whereby application developers can hint to a browser
how to
load a XmlHttpRequest.
Proposed API:
interface XMLHttpRequest {
// XMLHttpRequest Priorities.
const unsigned short CRITICAL = 0;
const unsigned short HIGH = 1;
const unsigned short LOW = 2;
const unsigned short LOWEST = 3;
// Set the load priority for this request.
void setPriority(unsigned short priority);
}
Example Usage:
var client = new XMLHttprequest;
client.setPriority(HIGH);
client.open(’GET’, ‘demo.cgi’);
client.send();
Description:
When a new XMLHttpRequest object is created, it contains a notion of
priority. Browsers which schedule resource fetches may
optionally use
this priority to determine in which order resources are fetched.
4 priorities are provided. By keeping the number of different
priorities small, we keep browser and XMLHttpRequest priority
implementations simple.
By default, all XMLHttpRequest objects have a priority ‘LOW’.
Applications may alter the priority by calling the setPriority()
method
on the XMLHttpRequest object. The priority set on the object at the
time the applicaiton calls the XMLHttpRequest.send() method
determines
the priority the browser should use when fetching this resource.
Calling setPriority() after the send() method will have no
