- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 09 Sep 2008 14:55:37 -0700
- To: Anne van Kesteren <annevk@opera.com>
- CC: WebApps WG <public-webapps@w3.org>
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 Tuesday, 9 September 2008 21:57:35 UTC