Re: XHR.responseBlob and BlobWriter [nee FileWriter]
On Tue, 29 Jun 2010 03:58:24 +0200, Eric Uhrhane er...@google.com wrote: XHR will have a responseBlob property. Indeed: http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#the-responseblob-attribute :-) (I also fixed the issue of not resetting the credentials flag and the request timeout when invoking open().) -- Anne van Kesteren http://annevankesteren.nl/
Re: XHR.responseBlob and BlobWriter [nee FileWriter]
On Tue, 17 Aug 2010 04:05:52 +0200, Michael Nordman micha...@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? (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/
Re: XHR.responseBlob and BlobWriter [nee FileWriter]
On Tue, 17 Aug 2010 05:35:20 +0200, Jonas Sicking jo...@sicking.cc wrote: Sounds good, though I think we let asBlob act is more like withCredentials and not get reset upon open(). Thus it can also be settable before open() as well. withCredentials is designed after setRequestHeader() so it is not settable before open(). -- Anne van Kesteren http://annevankesteren.nl/
Re: XHR.responseBlob and BlobWriter [nee FileWriter]
On Tue, 17 Aug 2010 21:14:03 +0200, Michael Nordman micha...@google.com wrote: On Mon, Aug 16, 2010 at 11:34 PM, Anne van Kesteren ann...@opera.comwrote: 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/
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 ann...@opera.com wrote: On Tue, 17 Aug 2010 21:14:03 +0200, Michael Nordman micha...@google.com wrote: On Mon, Aug 16, 2010 at 11:34 PM, Anne van Kesteren ann...@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/
Re: XHR.responseBlob and BlobWriter [nee FileWriter]
On Wed, 18 Aug 2010 00:24:56 +0200, Michael Nordman micha...@google.com wrote: 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. I suppose when asBlob is true and the state is not DONE it should simply return null like responseXML does for consistency. But when asBlob is false it should throw. See for responseXML: http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#the-responsexml-attribute 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. If we go with null above it should be null here too. Returning null is probably also better if we decide we want to expose the Blob as streaming entity at some point. I.e. while the state is LOADING. -- Anne van Kesteren http://annevankesteren.nl/
Re: XHR.responseBlob and BlobWriter [nee FileWriter]
On Tue, Aug 17, 2010 at 3:37 PM, Anne van Kesteren ann...@opera.com wrote: On Wed, 18 Aug 2010 00:24:56 +0200, Michael Nordman micha...@google.com wrote: 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. I suppose when asBlob is true and the state is not DONE it should simply return null like responseXML does for consistency. But when asBlob is false it should throw. Sounds good (here and below) ... thnx for the clarification. See for responseXML: http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#the-responsexml-attribute 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. If we go with null above it should be null here too. Returning null is probably also better if we decide we want to expose the Blob as streaming entity at some point. I.e. while the state is LOADING. -- Anne van Kesteren http://annevankesteren.nl/
Re: XHR.responseBlob and BlobWriter [nee FileWriter]
On Mon, Aug 16, 2010 at 7:05 PM, Michael Nordman micha...@google.com wrote: Hi All, 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? Michael Sounds good, though I think we let asBlob act is more like withCredentials and not get reset upon open(). Thus it can also be settable before open() as well. / Jonas
Re: XHR.responseBlob and BlobWriter [nee FileWriter]
On 6/28/10 6:58 PM, Eric Uhrhane wrote: The discussion at [1] got tangled up with the debate of .URL vs. .url, so I'm starting a new thread to pick back up the original topic: how do we save binary data from XMLHttpRequest? Here's my proposal [built mainly from the good ideas other folks posted in the original thread]. Use case 1: the developer wants to download a Blob of data, use it for a while [e.g. slicing out sub-Blobs and displaying them as images], then have it go away automatically. Use case 2: the developer wants to download a Blob of data, saving it in a location of the user's choice outside the sandbox. Use case 3: the developer wants to download a Blob of data, save it in the sandboxed FileSystem, and access it again later. XHR will have a responseBlob property. In order to signal the XHR that it should spool to disk and supply responseBlob, a flag must be set before send() is called. Call this wantBlob for now, although a better name would be appreciated. If wantBlob is set, responseBlob will be valid when the XHR completes, and responseText and responseXML will be null. If wantBlob is not set, responseBlob will be null, and the XHR will function as it does now. When wantBlob is set, on all progress events before the XHR is complete, responseBlob will be null. As of completion, it will return a Blob containing the full contents of the download. [We could later add incremental Blobs in progress events, but let's keep this simple to start with.] This satisfies use case 1 as-is. With the BlobWriter spec [2], as currently written [assuming we agree on how to get our hands on a BlobWriter], it takes care of use case 2. With the FileSystem spec [3], as currently written, it takes care of use case 3. I think this takes care of the major use cases, doesn't force anyone to implement FileSystem to solve the cases that don't really require it, removes any need for synchronous IO, and is pretty simple for developers to understand and use. What do you think? I personally think this sounds workable. We could also have a responseArrayBuffer using the TypedArrays[4] proposal which wouldn't necessarily need asynchronous processing. -- A* Eric [1] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0313.html [2] http://dev.w3.org/2009/dap/file-system/file-writer.html [3] http://dev.w3.org/2009/dap/file-system/file-dir-sys.html [4] https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html
Re: XHR.responseBlob and BlobWriter [nee FileWriter]
On Mon, Jun 28, 2010 at 6:58 PM, Eric Uhrhane er...@google.com wrote: The discussion at [1] got tangled up with the debate of .URL vs. .url, so I'm starting a new thread to pick back up the original topic: how do we save binary data from XMLHttpRequest? Here's my proposal [built mainly from the good ideas other folks posted in the original thread]. Use case 1: the developer wants to download a Blob of data, use it for a while [e.g. slicing out sub-Blobs and displaying them as images], then have it go away automatically. Use case 2: the developer wants to download a Blob of data, saving it in a location of the user's choice outside the sandbox. Use case 3: the developer wants to download a Blob of data, save it in the sandboxed FileSystem, and access it again later. XHR will have a responseBlob property. In order to signal the XHR that it should spool to disk and supply responseBlob, a flag must be set before send() is called. Call this wantBlob for now, although a better name would be appreciated. If wantBlob is set, responseBlob will be valid when the XHR completes, and responseText and responseXML will be null. If wantBlob is not set, responseBlob will be null, and the XHR will function as it does now. When wantBlob is set, on all progress events before the XHR is complete, responseBlob will be null. As of completion, it will return a Blob containing the full contents of the download. [We could later add incremental Blobs in progress events, but let's keep this simple to start with.] This satisfies use case 1 as-is. With the BlobWriter spec [2], as currently written [assuming we agree on how to get our hands on a BlobWriter], it takes care of use case 2. With the FileSystem spec [3], as currently written, it takes care of use case 3. I think this takes care of the major use cases, doesn't force anyone to implement FileSystem to solve the cases that don't really require it, removes any need for synchronous IO, and is pretty simple for developers to understand and use. What do you think? SGTM Eric [1] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0313.html [2] http://dev.w3.org/2009/dap/file-system/file-writer.html [3] http://dev.w3.org/2009/dap/file-system/file-dir-sys.html
Re: XHR.responseBlob and BlobWriter [nee FileWriter]
On Mon, Jun 28, 2010 at 6:58 PM, Eric Uhrhane er...@google.com wrote: The discussion at [1] got tangled up with the debate of .URL vs. .url, so I'm starting a new thread to pick back up the original topic: how do we save binary data from XMLHttpRequest? Here's my proposal [built mainly from the good ideas other folks posted in the original thread]. Use case 1: the developer wants to download a Blob of data, use it for a while [e.g. slicing out sub-Blobs and displaying them as images], then have it go away automatically. Use case 2: the developer wants to download a Blob of data, saving it in a location of the user's choice outside the sandbox. Use case 3: the developer wants to download a Blob of data, save it in the sandboxed FileSystem, and access it again later. XHR will have a responseBlob property. In order to signal the XHR that it should spool to disk and supply responseBlob, a flag must be set before send() is called. Call this wantBlob for now, although a better name would be appreciated. If wantBlob is set, responseBlob will be valid when the XHR completes, and responseText and responseXML will be null. If wantBlob is not set, responseBlob will be null, and the XHR will function as it does now. When wantBlob is set, on all progress events before the XHR is complete, responseBlob will be null. As of completion, it will return a Blob containing the full contents of the download. [We could later add incremental Blobs in progress events, but let's keep this simple to start with.] This satisfies use case 1 as-is. With the BlobWriter spec [2], as currently written [assuming we agree on how to get our hands on a BlobWriter], it takes care of use case 2. With the FileSystem spec [3], as currently written, it takes care of use case 3. I think this takes care of the major use cases, doesn't force anyone to implement FileSystem to solve the cases that don't really require it, removes any need for synchronous IO, and is pretty simple for developers to understand and use. What do you think? Sounds great to me! Also note that this will allow Use case 3': the developer wants to download a Blob of data, save it in IndexedDB, and access it again later. / Jonas
Re: XHR.responseBlob and BlobWriter [nee FileWriter]
On Tue, Jun 29, 2010 at 11:28 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Jun 28, 2010 at 6:58 PM, Eric Uhrhane er...@google.com wrote: The discussion at [1] got tangled up with the debate of .URL vs. .url, so I'm starting a new thread to pick back up the original topic: how do we save binary data from XMLHttpRequest? Here's my proposal [built mainly from the good ideas other folks posted in the original thread]. Use case 1: the developer wants to download a Blob of data, use it for a while [e.g. slicing out sub-Blobs and displaying them as images], then have it go away automatically. Use case 2: the developer wants to download a Blob of data, saving it in a location of the user's choice outside the sandbox. Use case 3: the developer wants to download a Blob of data, save it in the sandboxed FileSystem, and access it again later. XHR will have a responseBlob property. In order to signal the XHR that it should spool to disk and supply responseBlob, a flag must be set before send() is called. Call this wantBlob for now, although a better name would be appreciated. If wantBlob is set, responseBlob will be valid when the XHR completes, and responseText and responseXML will be null. If wantBlob is not set, responseBlob will be null, and the XHR will function as it does now. When wantBlob is set, on all progress events before the XHR is complete, responseBlob will be null. As of completion, it will return a Blob containing the full contents of the download. [We could later add incremental Blobs in progress events, but let's keep this simple to start with.] This satisfies use case 1 as-is. With the BlobWriter spec [2], as currently written [assuming we agree on how to get our hands on a BlobWriter], it takes care of use case 2. With the FileSystem spec [3], as currently written, it takes care of use case 3. I think this takes care of the major use cases, doesn't force anyone to implement FileSystem to solve the cases that don't really require it, removes any need for synchronous IO, and is pretty simple for developers to understand and use. What do you think? Sounds great to me! Also note that this will allow Use case 3': the developer wants to download a Blob of data, save it in IndexedDB, and access it again later. I don't see Blob mentioned in the structured clone algorithm, although File is there. I doubt it would be much additional work to support all Blobs. Eric
Re: XHR.responseBlob and BlobWriter [nee FileWriter]
On Tue, Jun 29, 2010 at 4:24 PM, Eric Uhrhane er...@google.com wrote: On Tue, Jun 29, 2010 at 11:28 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Jun 28, 2010 at 6:58 PM, Eric Uhrhane er...@google.com wrote: The discussion at [1] got tangled up with the debate of .URL vs. .url, so I'm starting a new thread to pick back up the original topic: how do we save binary data from XMLHttpRequest? Here's my proposal [built mainly from the good ideas other folks posted in the original thread]. Use case 1: the developer wants to download a Blob of data, use it for a while [e.g. slicing out sub-Blobs and displaying them as images], then have it go away automatically. Use case 2: the developer wants to download a Blob of data, saving it in a location of the user's choice outside the sandbox. Use case 3: the developer wants to download a Blob of data, save it in the sandboxed FileSystem, and access it again later. XHR will have a responseBlob property. In order to signal the XHR that it should spool to disk and supply responseBlob, a flag must be set before send() is called. Call this wantBlob for now, although a better name would be appreciated. If wantBlob is set, responseBlob will be valid when the XHR completes, and responseText and responseXML will be null. If wantBlob is not set, responseBlob will be null, and the XHR will function as it does now. When wantBlob is set, on all progress events before the XHR is complete, responseBlob will be null. As of completion, it will return a Blob containing the full contents of the download. [We could later add incremental Blobs in progress events, but let's keep this simple to start with.] This satisfies use case 1 as-is. With the BlobWriter spec [2], as currently written [assuming we agree on how to get our hands on a BlobWriter], it takes care of use case 2. With the FileSystem spec [3], as currently written, it takes care of use case 3. I think this takes care of the major use cases, doesn't force anyone to implement FileSystem to solve the cases that don't really require it, removes any need for synchronous IO, and is pretty simple for developers to understand and use. What do you think? Sounds great to me! Also note that this will allow Use case 3': the developer wants to download a Blob of data, save it in IndexedDB, and access it again later. I don't see Blob mentioned in the structured clone algorithm, although File is there. I doubt it would be much additional work to support all Blobs. Indeed, it should be trivial. I think Blob didn't exist yet at the time when the structured clone algorithm was last updated. / Jonas
