- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 22 Aug 2013 09:07:58 -0700
- To: Aymeric Vitte <vitteaymeric@gmail.com>
- Cc: "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>
I think you might have misunderstood my initial comment. I agree that the current partial data solution is not good. I think we should remove it. I think we should instead create a better solution in v2 of the API which is based on something other than FileReader and which has the ability to deliver data on the form of "here's the data that was loaded since last notification". / Jonas On Thu, Aug 22, 2013 at 3:35 AM, Aymeric Vitte <vitteaymeric@gmail.com> wrote: > Yes, "stucked" was not the right term, the workaround is to slice the blob > once the file has been readed and to use workers so the UA is not blocked by > the operation, both are indeed not great at all, taking a lot of time and > complicating the implementation while it could be easily implemented on a > streaming style, I will watch the API handling incremental data but I still > don't get the use of the partial blob as it is in the spec. > > Regards > > Aymeric > > Le 22/08/2013 01:21, Jonas Sicking a écrit : > >> On Wed, Aug 21, 2013 at 3:56 PM, Aymeric Vitte <vitteaymeric@gmail.com> >> wrote: >>> >>> Combination of the File API, indexedDB, etc (and future WebCrypto) is >>> really >>> great, I did not expect to be stucked by something that looks trivial: >>> calculate the hash of a file while you are reading it. >> >> Until we add API for incremental data, what you can do is to use >> Blob.slice() to read the blob in small parts. Not great, but at least >> it'll get you unstuck. >> >> / Jonas > > > -- > jCore > Email : avitte@jcore.fr > iAnonym : http://www.ianonym.com > node-Tor : https://www.github.com/Ayms/node-Tor > GitHub : https://www.github.com/Ayms > Web : www.jcore.fr > Extract Widget Mobile : www.extractwidget.com > BlimpMe! : www.blimpme.com >
Received on Thursday, 22 August 2013 16:09:03 UTC