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

Re: XHR.responseBlob and BlobWriter [nee FileWriter]

From: Michael Nordman <michaeln@google.com>
Date: Tue, 17 Aug 2010 12:14:03 -0700
Message-ID: <AANLkTimK+RnD6MDMOZ2G6CSpKppUNZBBoLweANma1qJW@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.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 Mon, Aug 16, 2010 at 11:34 PM, Anne van Kesteren <annevk@opera.com>wrote:

> On Tue, 17 Aug 2010 04:05:52 +0200, Michael Nordman <michaeln@google.com>
> wrote:
>
>> I'm interested in adding support for XHR.responseBlob to webkit and
>> chrome. It sounds like we have a general consensus to add two new members to
>> the
>> XmlHttpRequest interface:
>>
>>  attribute boolean asBlob;  // at least for the sake of discussion,
>> calling
>> it that for now
>>  readonly attribute Blob responseBlob;
>>
>> Another name option could be 'downloadAsBlob'. Personally, I like 'asBlob'
>> for its brevity and its naming similarity to  'withCredentials'.
>>
>> Looks like the semantics of when its valid to call setRequestHeaders also
>> applies setting the asBlob attribute; after open() but before send() has
>> been called. An attempt to set the value at some inappropriate time should
>> throw an INVALID_STATE exception. Also the asBlob attribute value should
>> probably be reset to 'false' upon return from open(), again similar to how
>> the request headers are cleared out upon return from open().
>>
>> Anne, have you been following this discussion, wdyt?
>>
>
> 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.

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)
- 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?

I think nothing else changes, incremental ready state changed events and
progress events should still fire as usual.


>
>
> (I think you also found a bug in that the "credentials flag" and "request
> timeout" are not reset when open() is invoked.)
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>
Received on Tuesday, 17 August 2010 19:14:58 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:40 GMT