Re: XHR.responseBlob and BlobWriter [nee FileWriter]

Here's the text I've put in the webkit (and chrome) bug reports for this
feature...
https://bugs.webkit.org/show_bug.cgi?id=44133
http://code.google.com/p/chromium/issues/detail?id=52486

Implement an XHR.responseBlob accessor to get an opaque reference to
the response data as a blob.

Two new additions for the XHR interface in support of this. This is
not solidified yet, still pending some discussion on the public lists.

boolean attribute asBlob;
// Prepares the XHR to make the response available as a blob object.
// Defaults to false, must be set after calling open() and
// prior to calling send(). Gets reset upon subsequent calls to open().
// Throws INVALID_STATE_ERR if set at an invalid time. Maybe read at
// anytime without exception.

Blob attribute responseBlob;
// Returns a blob the contains the response body.
// Only valid to access when asBlob is true and when the request is in
// a terminal state. Throws INVALID_STATE_ERR if accessed at an
// invalid time.

When asBlob is true, the other response accessors (responseText,
resonseXML, responseBody) throw INVALID_STATE_ERR if accessed.

We're making this "modal" for the benefit of the browser vendors, to
make it easier for them to know how to handle the response data as it
comes in. With a priori knowlege that the data need never be made
available thru the responseText attribute, life is a little easier for
them/us.

Also see http://code.google.com/p/chromium/issues/detail?id=52486


On Tue, Aug 17, 2010 at 3:13 PM, Anne van Kesteren <annevk@opera.com> wrote:

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


Ok... so is the "default value" for responseBlob an empty blob when asBlob
is true and the attribute is accessed while the XHR object is in a terminal
error or aborted state? Just looking to clarify whether the accessor should
 throw the invalid state error or return normally in these terminal states.


>
>
>  - 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/
>