Re: XMLHttpRequest.responseBlob

Ugh, sent this originally to just Darin. Resending to the list.

On Wed, Apr 28, 2010 at 10:11 AM, Darin Fisher <darin@chromium.org> wrote:
> 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.

Well, it seems like a bigger deal here since the file is being
constantly modified as we're downloading data into it, no? So for
example if you grab a File object after the first progress event, what
does that File object contain after the second? Does it contain the
whole file, including the newly downloaded data? Or does it contain
only the data after the first progress event? Or is the File object
now invalid and can't be used?

I'm also still unsure that a FileWriter is what you want generally. If
you're just downloading temporary data, but data that happens to be so
large that you don't want to keep it in memory, you don't want to
bother the user asking for a location for that temporary file. Nor do
you want that file to be around once the user leaves the page.

Sure, if the use case is actually downloading and saving a file for
the user to use, rather than for the page to use, then a FileWriter
seems like it would work. I.e. if you want something like
"Content-Disposition: attachment", but where you can specify request
headers. Is that the use case?

/ Jonas

Received on Wednesday, 28 April 2010 18:22:26 UTC