RE: [xmlhttprequest2] timeout and JSON
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
Re: [xmlhttprequest2] timeout and JSON
On Wed, Sep 17, 2008 at 3:03 AM, Sunava Dutta [EMAIL PROTECTED] wrote: Jonas said I guess IE doesn't have an abort event on the XHR object (is this correct?) so the relation between ontimeout and onabort is undefined as far as the IE implementation goes. Correct. We do have abort and timeout, and adding onabort in the future IE release will have to be considered so we should define the relationship. As you mentioned, a possible good definition of timeouts is that a 'timeout' event should fire (which will trigger ontimeout) and then abort() should be called which will result in an 'abort' even (which will trigger onabort). Sounds good to me. Would be great to hear what other people think on having timeout in general and the specifics regarding what should happen when the timeout fires. / Jonas
RE: [xmlhttprequest2] timeout and JSON
Jonas said I guess IE doesn't have an abort event on the XHR object (is this correct?) so the relation between ontimeout and onabort is undefined as far as the IE implementation goes. Correct. We do have abort and timeout, and adding onabort in the future IE release will have to be considered so we should define the relationship. As you mentioned, a possible good definition of timeouts is that a 'timeout' event should fire (which will trigger ontimeout) and then abort() should be called which will result in an 'abort' even (which will trigger onabort). -Original Message- From: Jonas Sicking [mailto:[EMAIL PROTECTED] Sent: Thursday, September 11, 2008 8:32 PM To: Sunava Dutta Cc: Anne van Kesteren; WebApps WG; Gideon Cohn; Zhenbin Xu; IE8 Core AJAX SWAT Team Subject: Re: [xmlhttprequest2] timeout and JSON Sunava Dutta wrote: I absolutely agree that it would rock if we could use the MS implementation. Thanks Jonas. As always, appreciated. Answers to your question What happens if there is a timeout in that state? 1) .readystate is set to 0 .status is set to 0 .responseXML is set to null .responseText is set to 2) All properties are left as is. 3) Something else (Profit?) Essentially, timeout has the effect that is similar to 1). Infact, design wise is intended to have the same effect although a few superficial differences exist. What 1) seems to ask for is resetting the object, which is what IE8 does. Readystate is set to 0, there are a few differences in IE's (8 and legacy) support for the existing XHR syntax, and those are reflected in the values of the properties when they are accessed in readystate 0 and corresponding exceptions thrown. Any changes to a future release of IE to bring those inline with the XHR spec would remedy the differences. These are: When ontimeout fires: • Getting responseText throws an exception: “The data necessary to complete this operation is not yet available” • Getting responseXML throws an exception: “Unspecified error.” • Getting status throws an exception: “Unspecified error.” Ah, so it sounds like timing out behaves very similarly to abort() being called? Does onreadystatechange fire since readystate changes to 0? And does this happen before or after ontimeout is fired? I guess IE doesn't have an abort event on the XHR object (is this correct?) so the relation between ontimeout and onabort is undefined as far as the IE implementation goes. / Jonas
RE: [xmlhttprequest2] timeout and JSON
Ah, so it sounds like timing out behaves very similarly to abort() being called? Does onreadystatechange fire since readystate changes to 0? And does this happen before or after ontimeout is fired? I guess IE doesn't have an abort event on the XHR object (is this correct?) so the relation between ontimeout and onabort is undefined as far as the IE implementation goes. Onreadystate change is updated to 0 but does not fire for 0. We don’t have an abort event on XHR object (of course, abort exists) so onabort currently is undefined. -Original Message- From: Jonas Sicking [mailto:[EMAIL PROTECTED] Sent: Thursday, September 11, 2008 8:32 PM To: Sunava Dutta Cc: Anne van Kesteren; WebApps WG; Gideon Cohn; Zhenbin Xu; IE8 Core AJAX SWAT Team Subject: Re: [xmlhttprequest2] timeout and JSON Sunava Dutta wrote: I absolutely agree that it would rock if we could use the MS implementation. Thanks Jonas. As always, appreciated. Answers to your question What happens if there is a timeout in that state? 1) .readystate is set to 0 .status is set to 0 .responseXML is set to null .responseText is set to 2) All properties are left as is. 3) Something else (Profit?) Essentially, timeout has the effect that is similar to 1). Infact, design wise is intended to have the same effect although a few superficial differences exist. What 1) seems to ask for is resetting the object, which is what IE8 does. Readystate is set to 0, there are a few differences in IE's (8 and legacy) support for the existing XHR syntax, and those are reflected in the values of the properties when they are accessed in readystate 0 and corresponding exceptions thrown. Any changes to a future release of IE to bring those inline with the XHR spec would remedy the differences. These are: When ontimeout fires: • Getting responseText throws an exception: “The data necessary to complete this operation is not yet available” • Getting responseXML throws an exception: “Unspecified error.” • Getting status throws an exception: “Unspecified error.” Ah, so it sounds like timing out behaves very similarly to abort() being called? Does onreadystatechange fire since readystate changes to 0? And does this happen before or after ontimeout is fired? I guess IE doesn't have an abort event on the XHR object (is this correct?) so the relation between ontimeout and onabort is undefined as far as the IE implementation goes. / Jonas
Re: [xmlhttprequest2] timeout and JSON
Jonas Sicking wrote: Sunava Dutta wrote: XDR timeout doesn’t work with sync requests as there is no sync support in the object. I'd be thrilled if IE9's timeout property be adopted for XHR. (OK, thrilled would be an understatement!) http://msdn.microsoft.com/en-us/library/cc304105(VS.85).aspx We fire an ontimeout and named it similar to other defined XHR2 events like onload etc to ease potential integration with XHR2! It works for sync and async calls. Of course, if needed we are amenable to making tweaks down the road to the property/event behavior if necessary, but ideally it would be picked up 'as is'. How do other properties, like .readystate, .responseXML, .responseText, .status interact with timing out? I.e. say that we have an XHR object currently loading in the following state: xhr.readystate = 3 xhr.status = 200 xhr.responseText = resultelhello worl xhr.responseXML = #document result el #text: hello worl (sorry, trying to draw a DOM, not very obvious what it is) What happens if there is a timeout in that state? 1) .readystate is set to 0 .status is set to 0 .responseXML is set to null .responseText is set to 2) All properties are left as is. 3) Something else (Profit?) If the answer is 1, does that happen before or after ontimeout is fired? And does that mean that onreadystatechange is called? If the answer is 2, does this mean that no action at all is taken other than ontimeout getting called? onreadystatechange is not fired any more unless someone explicitly calls .abort() and then .open()? To make it clear. I absolutely agree that it would rock if we could use the MS implementation. However it needs to be specified in more detail than the MSDN page includes, such as answers to the questions above. / Jonas
RE: [xmlhttprequest2] timeout and JSON
I absolutely agree that it would rock if we could use the MS implementation. Thanks Jonas. As always, appreciated. Answers to your question What happens if there is a timeout in that state? 1) .readystate is set to 0 .status is set to 0 .responseXML is set to null .responseText is set to 2) All properties are left as is. 3) Something else (Profit?) Essentially, timeout has the effect that is similar to 1). Infact, design wise is intended to have the same effect although a few superficial differences exist. What 1) seems to ask for is resetting the object, which is what IE8 does. Readystate is set to 0, there are a few differences in IE's (8 and legacy) support for the existing XHR syntax, and those are reflected in the values of the properties when they are accessed in readystate 0 and corresponding exceptions thrown. Any changes to a future release of IE to bring those inline with the XHR spec would remedy the differences. These are: When ontimeout fires: • Getting responseText throws an exception: “The data necessary to complete this operation is not yet available” • Getting responseXML throws an exception: “Unspecified error.” • Getting status throws an exception: “Unspecified error.” -Original Message- From: Jonas Sicking [mailto:[EMAIL PROTECTED] Sent: Thursday, September 11, 2008 3:21 AM To: Sunava Dutta Cc: Anne van Kesteren; WebApps WG; Gideon Cohn; Zhenbin Xu; IE8 Core AJAX SWAT Team Subject: Re: [xmlhttprequest2] timeout and JSON Jonas Sicking wrote: Sunava Dutta wrote: XDR timeout doesn’t work with sync requests as there is no sync support in the object. I'd be thrilled if IE9's timeout property be adopted for XHR. (OK, thrilled would be an understatement!) http://msdn.microsoft.com/en-us/library/cc304105(VS.85).aspx We fire an ontimeout and named it similar to other defined XHR2 events like onload etc to ease potential integration with XHR2! It works for sync and async calls. Of course, if needed we are amenable to making tweaks down the road to the property/event behavior if necessary, but ideally it would be picked up 'as is'. How do other properties, like .readystate, .responseXML, .responseText, .status interact with timing out? I.e. say that we have an XHR object currently loading in the following state: xhr.readystate = 3 xhr.status = 200 xhr.responseText = resultelhello worl xhr.responseXML = #document result el #text: hello worl (sorry, trying to draw a DOM, not very obvious what it is) What happens if there is a timeout in that state? 1) .readystate is set to 0 .status is set to 0 .responseXML is set to null .responseText is set to 2) All properties are left as is. 3) Something else (Profit?) If the answer is 1, does that happen before or after ontimeout is fired? And does that mean that onreadystatechange is called? If the answer is 2, does this mean that no action at all is taken other than ontimeout getting called? onreadystatechange is not fired any more unless someone explicitly calls .abort() and then .open()? To make it clear. I absolutely agree that it would rock if we could use the MS implementation. However it needs to be specified in more detail than the MSDN page includes, such as answers to the questions above. / Jonas
Re: [xmlhttprequest2] timeout and JSON
Anne van Kesteren wrote:
On Fri, 05 Sep 2008 02:36:58 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
1. A timeout property like the one on microsofts XDR. I haven't looked
into the specifics of XDRs property, but I would think that an
'abort' event should fire as well as readystate transitioning to
something if the timeout is reached.
What's wrong with using setTimeout?
Doesn't work with synchronous requests. Or at least sort of. It's
somewhat undefined if timers and UI events should fire during
synchronous XHR loads, but it seems like a lot of people expect at least
timers not to. So for this I'm assuming that that is the case.
(If anyone is interested, FF2 did not fire timers, FF3 does)
Timeouts are especially import during synchronous requests since they
block the UI, so you don't want to do that for too long periods of time.
2. A .responseJSON property. This would return the same thing as the
following code:
if (xhr.readyState != 4) {
return null;
}
return JSON.parse(xhr.responseText);
However there are a few details that can be quibbled about:
a) Should a partial result be returned during readystate 3
b) If the property is gotten multiple times, should that return the
same or a new object every time.
What's wrong with using JSON.parse?
Partially convenience.
Partially for completeness with .responseXML.
Partially to discourage people from sending data using XML just because
the object is called XMLHttpRequest.
(I'm not necessarily opposed, but I'd like to only add features that are
necessary.)
Agreed, my bad for not including use cases initially.
/ Jonas
