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
