Re: XMLHttpRequest.responseBlob

On Tue, Apr 27, 2010 at 1:33 PM, Jonas Sicking <jonas@sicking.cc> wrote:

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

When you use createWriter, you are creating a FileWriter to an existing
File.
The user could attempt to create a FileReader to the very same File while
a FileWriter is open to it.

It is true that for <input type=saveas> there is no way to get at the
underlying
File object.  That is perhaps a good thing for the use case of downloading
to
a location specified by the user.



>
> > 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?
>
>
See above.

-Darin

Received on Tuesday, 27 April 2010 21:00:02 UTC