Re: XMLHttpRequest Priority Proposal

Finally cycling back on this.

Based on feedback from Olli and Anne, I have revised the spec.

Changes:
   * changed the setPriority() method to be an attribute "priority"
   * made priority be a string rather than a number
   * inserted the "NORMAL" priority as the default XHR priority

Here is the updated doc.

Olli has implemented a patch (for the old spec) already:
https://bugzilla.mozilla.org/show_bug.cgi?id=559092
We'll be working on a Chromium/Webkit one shortly.

Mike


XMLHttpRequest Priority FetchingEvery 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 {
 // Set the load priority for this request.
 // The priority must be set before calling send().
 // Valid priorities are:
 //   “CRITICAL”, “HIGH”, “NORMAL”, “LOW”, “LOWEST”
 attribute string priority;
}

Example Usage:
var client = new XMLHttprequest;
client.priority = “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.

5 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 “NORMAL”.

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-LOWEST resources are deferred until all CRITICAL
resources have finished.
  HIGH-LOWEST resources are loaded in that order.  When no CRITICAL
resources are in progress, HIGH-LOWEST 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.










On Sun, Apr 18, 2010 at 10:37 PM, Anne van Kesteren <annevk@opera.com>wrote:

> On Fri, 16 Apr 2010 18:03:08 +0900, Mike Belshe <mbelshe@google.com>
> wrote:
>
>> On Fri, Apr 16, 2010 at 1:37 AM, Anne van Kesteren <annevk@opera.com>
>> wrote:
>>
>>> I didn't actually propose an error condition and I'll note that your
>>> setPriority() proposal didn't handle errors either. E.g. what happens
>>> when I pass 20 as argument?
>>>
>>
>> Fair enough. :-)
>>
>> What I wanted was an enum, but I don't believe there is a way to do enums,
>> right?
>>
>
> Not currently, no.
>
>
>
>  I think easiest would be to just ignore the setting as e.g. lineCap and
>>> lineJoin on the canvas 2D API do. Then errors are gracefully handled and
>>> by
>>> checking what priority is after setting you can see whether the
>>> implementation supports the feature.
>>>
>>
>> I'd take whatever people like most.  Personally, I don't like using
>> strings for enums, but I can live with it.
>>
>> So you're proposing something like:
>>
>>   var my_priority = "HGIH";
>>   xhr.priority = my_priority;
>>   if (xhr.priority != my_priority)  {
>>     // we detected an error
>>   }
>>
>
> Yeah. Basically using strings makes it easier to extend the API going
> forward as numbers start clashing pretty soon.
>
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>