Re: Some XHR comments

On Wed, 05 Apr 2006 03:22:36 +0200, Cameron McCormack <cam@mcc.id.au>  
wrote:
> [...]
> alternative, DOMImplementation?).

Yeah, not sure which one is better... I'm also not sure whether to do it  
for version 1.0 or version 2.0 just wanted to make sure it's not  
impossible to do later on.


> 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:
>
> [...]
>
> 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.

Thanks for that! I don't think it will be reflected in the First Public  
Working Draft, but we'll look into it and if it's correct probably include  
it in a later version.


> 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.

Interesting, we should probably look into this.


>> [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.

I agree. I actually want XHR to be an EventTarget as well because it makes  
sense, but the only problem is that there's no implementation for that...


> 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).

Yeah, there should be an open issue on that. I'd like `this` to return the  
XMLHttpRequest object. Opera does that. Internet Explorer and Safari  
return the Window object. Mozilla returns the Function object you passed  
to onreadystatechange...


> 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.

Not sure if it has to be ES-specific, but yes. It's like:

  obj.onload
  obj.onerror

... etc. When people use that in most UAs you can also do:

  obj.addEventListener('load', ...)
  obj.addEventListener('error', ...)

...


>> [re readyState == 3]
>> What about HEAD requests?
>
> Perhaps the wording should be something like:
>
>   Immediately [after] all HTTP headers have been received.
>
> And also mention somewhere that HEAD requests would run
> onreadystatechange for readyState == 4 immediately after
> readyState == 3.

Yeah, something like that.


>> [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.

You mean methods? What about methods other specifications are introducing?


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Wednesday, 5 April 2006 08:10:49 UTC