W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2008

Re: [xmlhttprequest2] timeout and JSON

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 10 Sep 2008 14:11:01 -0700
Message-ID: <48C837E5.5010006@sicking.cc>
To: Sunava Dutta <sunavad@windows.microsoft.com>
CC: Anne van Kesteren <annevk@opera.com>, WebApps WG <public-webapps@w3.org>, Gideon Cohn <gidco@windows.microsoft.com>, Zhenbin Xu <Zhenbin.Xu@microsoft.com>, IE8 Core AJAX SWAT Team <ieajax@microsoft.com>

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 = "<result><el>hello 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()?

/ Jonas

>> -----Original Message-----
>> From: public-webapps-request@w3.org [mailto:public-webapps-
>> request@w3.org] On Behalf Of Jonas Sicking
>> Sent: Tuesday, September 09, 2008 2:56 PM
>> To: Anne van Kesteren
>> Cc: WebApps WG
>> Subject: Re: [xmlhttprequest2] timeout and JSON
>>
>>
>> Anne van Kesteren wrote:
>>> On Fri, 05 Sep 2008 02:36:58 +0200, Jonas Sicking <jonas@sicking.cc>
>> 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
>>
> 
Received on Wednesday, 10 September 2008 21:13:05 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:27 GMT