Re: XMLHttpRequest Priority Proposal

Hi,

this seems like a pretty useful, yet reasonable easily implementable
feature.
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?


-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 effect on
> the priority of the resource load.
>
> Browsers are not required to support the priority requested by
> applications, and may ignore it altogether.  However, browsers are
> encouraged to support the requested priority order.  The following is a
> description of one possible prioritization policy:
>    CRITICAL resources are loaded first.  When CRITICAL resources are in
> progress, requests for HIGH/MEDIUM/LOW resources are deferred until all
> CRITICAL resources have finished.
>    HIGH/MEDIUM/LOW resources are loaded in that order.  When no CRITICAL
> resources are in progress, HIGH/MEDIUM/LOW resources will be loaded with
> HIGH priority first.  The browser does not need to wait until higher
> priority resources have finished fetching before it starts a request for
> a lower priority resource, although it may chose to do so.
>
> Existing Implementations:
> Google is currently using resource prioritization techniques in its
> Google Maps application, internally to the Google Chrome browser, and
> also as a part of the SPDY protocol.

Received on Tuesday, 13 April 2010 16:37:16 UTC