RE: [xmlhttprequest2] timeout and JSON

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'.

> -----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 19:42:48 UTC