Re: XMLHttpRequest.responseBlob

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

> On Tue, Apr 27, 2010 at 1:59 PM, Darin Fisher <darin@chromium.org> wrote:
> > 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.
>
> Ah. But as far as I can tell (and remember), it's still fairly
> undefined what happens when the OS file under a File/Blob object is
> mutated.
>
> / Jonas
>

Agreed.  I don't see it as a big problem.  Do you?  The application
developer is
in control.  They get to specify the output file (via FileWriter) that XHR
sends its
output to, and they get to know when XHR is done writing.  So, the
application
developer can avoid reading from the file until XHR is done writing.

-Darin