Re: XMLHttpRequest.responseBlob

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

Received on Tuesday, 27 April 2010 21:05:28 UTC