- From: Anne van Kesteren <annevk@opera.com>
- Date: Wed, 18 Aug 2010 00:13:22 +0200
- To: "Michael Nordman" <michaeln@google.com>
- Cc: "Web Applications Working Group WG" <public-webapps@w3.org>, "Eric Uhrhane" <ericu@google.com>, "Jonas Sicking" <jonas@sicking.cc>, "Darin Fisher" <darin@chromium.org>, "James Robinson" <jamesr@google.com>, "Thomas Broyer" <t.broyer@gmail.com>
On Tue, 17 Aug 2010 21:14:03 +0200, Michael Nordman <michaeln@google.com> wrote: > On Mon, Aug 16, 2010 at 11:34 PM, Anne van Kesteren > <annevk@opera.com>wrote: >> Yeah I have. This design looks rather good. We should also define what >> happens to responseText and responseXML in this scenario. I suppose >> throwing >> INVALID_STATE_ERR makes the most sense to make it clear they are not >> available. Nothing else should be affected right? > > INVALID_STATE_ERR works. If responseText throws when asBlob is true, then > resposneBlob should throw when asBlob is false. Another plausible > option is to return NULL or UNDEFINED from these calls in those cases. > Either way > works, personally I like the unambiguous INVALID_STATE_ERR. Good point about responseBlob. Lets go for the exception. > The responseBlob attribute should be available for access when the 'done' > events are raised, so withing the event handler, the caller should be > able to access that attribute and get final results. Here's what i'm > referring to as the 'done' events... > - onerror (responseBlob yields whatever partial results there were if > any) Currently for network errors (i.e. not "errors" such as HTTP 410) everything will return their default value. Is there a good reason to do this differently for responseBlob? > - onload > - onloadend > - readystate changing to DONE > The only one I wonder about is onabort, what is the behavior of accessing > reponseBlob in that terminating condition? Same as for onerror at the moment. > I think nothing else changes, incremental ready state changed events and > progress events should still fire as usual. Yes. (I'm going to wait at least a week or so with updating the draft to include this (and other) feature(s). XMLHttpRequest and XMLHttpRequest Level 2 are created from the same source document and I would like to give priority to integrating the proposed changes for XMLHttpRequest (Level 1) for which I hope to have WG consensus declared next week.) -- Anne van Kesteren http://annevankesteren.nl/
Received on Tuesday, 17 August 2010 22:14:03 UTC