Some XHR comments

Hi.

Some responses to the remaining editorial notes in XHR:

> [re getting an XMLHttpRequest object]
> What about non-ECMAScript implementations?

If you want to worry about non-ECMAScript implementations (which may
conflict with "The goal of this specification is to document a minimum
set of interoperable features based on existing implementations", but
perhaps it's a good idea to allow other languages from the start), then
you will have to provide a mechanism for getting a new XMLHttpRequest
object that doesn't rely on ES-specifics such as calling [[Construct]]
on some function object.  Some interface would have to provide a
function that creates an XMLHttpRequest, such as

  interface WindowXMLHttpRequest {
      XMLHttpRequest createXMLHttpRequest();
  }

and then objects that implement Window could be required to implement
WindowXMLHttpRequest if the implementation supports XHR (assuming Window
objects are the most appropriate for this; what would be the
alternative, DOMImplementation?).

Is it worth specifying exactly how "In ECMAScript, an instance of
XMLHttpRequest can be created using the XMLHttpRequest() constructor"?
If so, perhaps it should be something along these lines:

  In ECMAScript, the global object must have a property named 'XMLHttpRequest'
  with the attribute { DontEnum } and no others.  The value of this
  property is an object (hereafter called the "XMLHttpRequest
  constructor") with the following properties:

    Property		Value

    [[Prototype]]	The Function prototype object
    [[Class]]		"Function"
    [[Call]]		See prose below.
    [[Construct]]	See prose below.
    length		0
    prototype		See prose below.

  In addition, then [[Get]], [[Put]], [[CanPut]], [[HasProperty]],
  [[Delete]] and [[DefaultValue]] internal properties must be present
  and behave as for native objects (as described in ECMA-262 8.6.2).

  When called as a function or a constructor, the XMLHttpRequest
  constructor creates a returns a new XMLHttpRequest object with initial
  values as described in section 3.  The newly created XMLHttpRequest
  object has its [[Prototype]] property set to the initial value of
  XMLHttpRequest.prototype.
  
  [Note: Should it be defined whether a TypeError exception is thrown
  if arguments are given to the constructor?]

  The XMLHttpRequest constructor's length property has attributes
  { ReadyOnly, DontDelete, DontEnum } and no others.  The prototype
  property has the attribute { DontEnum } and no others.

  The value of the XMLHttpRequest constructor's prototype property is an
  object (the "XMLHttpRequest prototype") with the following properties:

    Property		Value

    [[Prototype]]	The Object prototype object
    [[Class]]		"XMLHttpRequest"
    constructor		The XMLHttpRequest constructor

  In addition, the XMLHttpRequest prototype has properties that
  correspond to the methods and attributes in the IDL in section 3.

This is somewhat verbose, but is certainly better than the type of text
in http://www.w3.org/TR/DOM-Level-2-Core/ecma-script-binding.html, for
example.

While XMLHttpRequest, as a host object, does not have to behave like
native objects, for consistency I think it is advantageous if it does.
Opera seems to implement it mostly as I've described.  Mozilla is a
little different, in that the XMLHttpRequest constructor is not a
function and also does not have a length property.  The XMLHttpRequest
constructor's prototype property is ReadOnly in Opera, but not in
Mozilla.  I haven't tested other UAs.

> [re onreadystatechange]
> What if languages don't have functions? Perhaps this should be an
> EventListener?

An EventListener has the advantage of being an existing interface, but
somehow it seems weird to use it if XHR isn't an EventTarget.  There's
also the issue of what you pass as the Event object to handleEvent.  I
notice that Mozilla recently made a decision wrt this
(https://bugzilla.mozilla.org/show_bug.cgi?id=198595).  If XHR were an
EventTarget that you could do an addEventListener on as well as assign
to onreadystatechange, and have onreadystatechange just be an
ES-specific property, that would make sense to me.

> [re readyState == 3]
> What about HEAD requests?

Perhaps the wording should be something like:

  Immediately all HTTP headers have been received.

And also mention somewhere that HEAD requests would run
onreadystatechange for readyState == 4 immediately after
readyState == 3.

> [re open's method argument]
> What about PUT and DELETE?

I don't see any reason (except for the stated goal of finding a common
baseline on all implementations) to exclude some HTTP headers.


-- 
 Cameron McCormack			ICQ: 26955922
 cam (at) mcc.id.au			MSN: cam (at) mcc.id.au
 http://mcc.id.au/			JBR: heycam (at) jabber.org

Received on Wednesday, 5 April 2006 01:22:52 UTC