I just read through this thread, and found it really interesting. Figured I would chime in with my opinions, for whatever that's worth.
Firstly, let me explain I run a project called flXHR (http://flxhr.flensed.com) which is an XHR clone variant with cross-domain Ajax capability (using invisible flash). It implements an identical API to the regular XHR object, so it can be dropped in as a replacement and should behave quite similarly. So, my interest in this discussion is that I of course want to keep flXHR API compatible (as much as possible) with regular XHR implementations in the browsers. 1. With respect to "responseJSON", I think this is a good idea. However, I would just say that I think there's some inefficiency when a single response is translated into binary (IE), XML, JSON, text, etc. Very rarely will a single response be applicable to all those formats. So either the conversion fails for the non-applicable formats, or at least there's some processing time spent needlessly trying to convert to XML when it's not well formed XML in the first place, for instance. Perhaps the implementations already take care of this by first validating if a block of text can in fact be converted to that type. But again, even this check must take some processing time. The other thing to consider is how these properties are represented during readyState=3. Text based representation (and even binary) is probably not an issue, but I'm sure that there's got to be some sort of special processing to represent the "responseXML" as a well formed (auto-node-completed?) XMLdocument when it's only partially downloaded. The same issue would apply to creating a partial JSON object. And I'm not sure how "expensive" such logic is. Just thinking maybe to avoid some of that, these "properties" could be on-demand in some way, so that the object doesn't try to do the conversion until it's requested... requires them to be implemented as accessors rather than actual properties, but maybe it would help? Just something to consider. 2. With respect to "ontimeout" event. I implemented this in flXHR (seeing that IE8 was going to support it), but it looks like I inadvertently took a slightly different take on it (since IE8 was still in early beta when I did flXHR originally). In my opinion, the timeout event is more appropriately applicable in the period of time before any response has been returned (between state 2 and 3/4). Once some response has come back (all or partial), it seems like the timeout is less important/applicable. Maybe this is just opinion and may differ with a lot of different people. But if "ontimeout" were defined to only fire if the timeout happens before any part of the response comes back, all the questions raised about what to do with the partially filled properties (empty them, reset, abort, etc) would be moot. That's how my "ontimeout" works. But now that I realize it diverges from IE8's implementation, I may need to revisit it, unless you agree that it's a simpler, better way to approach the timeouts. Certainly, I will follow this discussion more closely to see the outcomes. Thanks for your time and consideration on my opinions. --Kyle Simpson
