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

Re: XHR.responseBlob and BlobWriter [nee FileWriter]

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>
Message-ID: <op.vhlr0khe64w2qv@anne-van-kesterens-macbook-pro.local>
On Tue, 17 Aug 2010 21:14:03 +0200, Michael Nordman <michaeln@google.com>  
> 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.


(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
Received on Tuesday, 17 August 2010 22:14:03 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:26 UTC