Re: File API: reading a Blob

Arun,

Streams will solve this, assuming they are implemented by all related 
APIs (this is not obvious, most of WGs seem not to care at all now that 
they have implemented their own so-called streams)

Quoting your other answer:

Well, the bug that removed them is:https://www.w3.org/Bugs/Public/show_bug.cgi?id=23158  and dates to last year.

Indeed, you removed this right away after I mentioned to the group last 
year that it was not implemented inside browsers and that, designed as 
it was (to display a progress bar), it seemed not very useful, but I 
insisted at that time that what was useful was to have the delta data, 
so I don't really see a consensus of not implementing partial data.

2. Use cases. MOST reads are useful with all data, after which you could use Blob manipulation (e.g.*slice*). New result objects each time didn’t seem optimal. And, it was something punted to Streams since that seemed like a longer term direction. There was also the idea of a Promise-based File API that could be consumed by the FileSystem API.

I don't get this, most reads inside browsers are about fetching, and 
fetching does increment a resource while it is loaded/displayed (image, 
video, crypto operations, etc)

And it's question of the fetch API in this thread.

XHR has the same issue, fortunately you can use XHR with Range, now I 
think this issue should stop propagating.

1. Decoding was an issue with*readAsText*. I suppose we could make that method alone be all or nothing.

I don't see where the issue can be, it should behave like textdecoder 
and reinject the undecoded bytes to the next chunk, personnaly I find 
really useless to offer the 'text' methods in files/fetching APIs.

So, I would insist again that you go for 1, whether it's promises like, 
append like, filewriter like, we must get access to partial data and we 
must be able to increment a blob (as well as its storage in indexedDB, 
other remark sent to the group some time ago, maybe you can combine both 
for the implementation since I don't really know what gets broken in the 
abstract model you mention)

Regards

Aymeric


Le 17/07/2014 15:10, Arun Ranganathan a écrit :
> Aymeric,
>
> On Jul 16, 2014, at 8:20 AM, Aymeric Vitte <vitteaymeric@gmail.com 
> <mailto:vitteaymeric@gmail.com>> wrote:
>
>> Example:
>> var myfile=new Blob();
>>
>> //chunks are coming in
>> myfile=new Blob([myfile,chunk],...)
>>
>> //mylink A tag
>> mylink.href=URL.createObjectURL(myfile)
>>
>> click on mylink --> does not work
>>
>> Expected behavior: the file (a video for example) should play as it 
>> is incremented.
>>
>> This is inconsistent with the standard files behavior (see [1] for 
>> example), this example should work without having to use the Media 
>> Source Extensions API.
>
>
> This is a great use case, but breaks File API currently (and the 
> abstract model, too).
>
> Options to consider might be:
>
> 1. Including partial Blob data with the existing FIle API. But we 
> already ship as is, so we could forego decoding to get this right, but 
> that doesn’t seem optimal either.
>
> 2. Use a new API for this, such as Streams. Since we’ll use streams 
> for non-file cases, it could be useful here (and might be a better fit 
> for the use case, which features heavy video use).
>
> — A*

-- 
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms