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: Thu, 04 Sep 2014 10:54:22 +0200
Message-ID: <540828BE.2010409@gmail.com>
To: Arun Ranganathan <arun@mozilla.com>
CC: Anne van Kesteren <annevk@annevk.nl>, Web Applications Working Group WG <public-webapps@w3.org>, Domenic Denicola <domenic@domenicdenicola.com>, Kyle Huey <me@kylehuey.com>, Joshua Bell <jsbell@google.com>, Takeshi Yoshino <tyoshino@google.com>

I know you (File API) care about it, I was more refering to other groups 
that seem not to care a lot, leading to absurd situations where we are 
streaming things without streams and have to implement some strange 
inadapted mechanisms for flow control/backpressure for example.

The examples I gave in this thread are just a small subset of what I 
(everybody) need, which involves all the groups listed below.

Despite of the fact that the spec is probably mature enough, I am not 
sure it can really be finalized without parallel field experimentation, 
which to work well needs to involve several groups and browsers from 
now, despite of the efforts of people involved the process is really too 

If we take the File API to address your concern, probably the question 
is not whether the earlier (or whatever) version should be modified 
(because the answer would be obviously yes for me, use cases are legion) 
but to make it work on the field with streams and finalize the spec 
accordingly, same thing for the other APIs.



Le 04/09/2014 02:39, Arun Ranganathan a ťcrit :
> On Sep 3, 2014, at 6:02 PM, Aymeric Vitte <vitteaymeric@gmail.com 
> <mailto:vitteaymeric@gmail.com>> wrote:
>> The fact is that most of the W3C groups impacted by streams (File, 
>> indexedDB, MSE, WebRTC, WebCrypto, Workers, XHR, WebSockets, Media 
>> Stream, etc, I must forget a lot here) seem not to care a lot about 
>> it and maybe just expect streams to land in the right place in the 
>> APIs when they are available, by some unknown magic.
> I care about it. Till the API is totally baked, Iím amenable to 
> getting the model right. File API now refers to chunks read, which is 
> more correct. But I understand that your use cases arenít catered to 
> just yet; FileReader/FileReaderSync donít do easily extractable partials.
> Iíd like to see if thereís interest in the earlier proposal, to 
> extract a stream straight from Blob.
>> I still think that the effort should start from now for all the APIs 
>> (as well as the implementation inside browsers, which apparently has 
>> started for Chrome, but Chrome was supposed to have started some 
>> implementation of the previous Streams APIs, so it's not very clear), 
>> and that it should be very clearly synchronized, disregarding vague 
>> assumptions from the groups about low/high level and Vx releases, 
>> eluding the issue.
> What issue is being eluded? Seems like another of your main use cases 
> is to have URL.createObjectURL or URL.createFor return a streamable 
> resource. I agree thatís a good problem to solve.
> ó A*

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 Thursday, 4 September 2014 08:54:42 UTC

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