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: [EMAIL PROTECTED] [mailto:public-webapps-
[EMAIL PROTECTED] 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 <[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




Reply via email to