W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: XMLHttpRequest.responseBlob

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 27 Apr 2010 13:33:29 -0700
Message-ID: <j2j63df84f1004271333qfed3f847k83704d1ebe8a18df@mail.gmail.com>
To: Darin Fisher <darin@chromium.org>
Cc: Web Applications Working Group WG <public-webapps@w3.org>
On Tue, Apr 27, 2010 at 1:26 PM, Darin Fisher <darin@chromium.org> wrote:
>> It would be nice to be able to allow streaming such that every time a
>> progress event is fired only the newly downloaded data is available.
>> The UA is then free to throw away that data once the event is done
>> firing. This would be useful in the cases when the page is able to do
>> incremental parsing of the resulting document.
>> If we add a 'load mode' flag on XMLHttpRequest, which can't be
>> modified after send() is called, then streaming to a Blob could simply
>> be another enum value for such a flag.
>> There is still the problem of how the actual blob works. I.e. does
>> .responseBlob return a new blob every time more data is returned? Or
>> should the same Blob be constantly modifying? If modifying, what
>> happens to any in-progress reads when the file is modified? Or do you
>> just make the Blob available once the whole resource has been
>> downloaded?
> This is why I suggested using FileWriter.  FileWriter already has to
> deal with
> most of the problems you mentioned above,

Actually, as far as I can tell FileWriter is write-only so it doesn't
deal with any of the problems above.

> and you can get a FileWriter
> either from <input type=saveas> [1] or from a FileEntry object [2].
> One possible API for engaging this mode might be:
> var x = new XMLHttpRequest();
> x.open("GET", url, true);
> x.streamToFile(fileWriter);
> x.send(null);

And how would you get the actual data?

/ Jonas
Received on Tuesday, 27 April 2010 20:34:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:07 UTC