W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2014

Re: File API: reading a Blob

From: Aymeric Vitte <vitteaymeric@gmail.com>
Date: Sun, 24 Aug 2014 23:59:44 +0200
Message-ID: <53FA604F.7090706@gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>, Arun Ranganathan <arun@mozilla.com>
CC: Web Applications Working Group WG <public-webapps@w3.org>, Domenic Denicola <domenic@domenicdenicola.com>, Kyle Huey <me@kylehuey.com>, Joshua Bell <jsbell@google.com>
Back in this thread lately too...

I still don't see how you intend to solve the use case I gave:

- load 'something' progressively, get chunks (should be possible via xhr 
but it's not)
- handle it via File augmenting the related Blob (not possible) and 
store it progressively in indexedDB (not possible too), or do the 
contrary, store it progressively and get it as an (uncomplete) Blob from 
indexedDB that will get augmented while it is stored (not possible again)
- URL.createObjectURL(something) (will not work)

where 'something' has a size of 1 GB (video for example)

That's equivalent to do with your browser:

file:/something or http://abcd.com/something where something is a file 
on you computer being downloaded or on a web site, so not complete.

Which works very well since a long time.

File, XHR and indexedDB should handle partial data, I thought I 
understood from messages last year that it was clearly identified as a 
mistake.

Regards,

Aymeric

Le 11/08/2014 13:24, Anne van Kesteren a écrit :
> On Fri, Aug 8, 2014 at 5:56 PM, Arun Ranganathan <arun@mozilla.com> wrote:
>> I strongly think we should leave FileReaderSync and FileReader alone. Also note that FileReaderSync and XHR (sync) are not different, in that both don’t do partial data. But we should have a stream api that evolves to read, and it might be something off Blob itself.
> Seems fair.
>
>
>> Other than “chunks of bytes” which needs some normative backbone, is the basic abstract model what you had in mind? If so, that might be worth getting into File APi and calling it done, because that’s a reusable abstract model for Fetch and for FileSystem.
> Yeah that looks good. https://whatwg.github.io/streams/ defines chunks
> and such, but is not quite there yet. But it is what we want to build
> this upon eventually.
>

-- 
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
Received on Sunday, 24 August 2014 22:00:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:26 UTC