Re: File API: reading a Blob

Arun,

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 
long.

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.

Regards,

Aymeric

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