Re: File API - Progress - Question about Partial Blob data

The Streams API says for now "This event handler should mimic the 
|FileReader.onprogress| 
<http://dev.w3.org/2006/webapi/FileAPI/#dfn-onprogress> event handler."...

The second proposal is not very explicit for now but there is a "read 
resolver".

This discussion seems to be the same as the "Overlap between 
StreamReader and FileReader" thread.

Now, I don't know what is the plan for the File API V2/Streams API 
(Promises? Schedule?) probably I am missing some details but I don't see 
what's the difficulty to replace the partial Blob as it is today by 
delta data (both for Files and Streams), the API does not have to care 
about non consumed data since the 
reader/parser/whatever_handles_the_data takes care of it (as long as 
delta data passed to the callback are not modified by the read, cf the 
example I gave for the above thread)

Regards,

Aymeric


Le 27/08/2013 01:37, Kenneth Russell a écrit :
> On Fri, Aug 23, 2013 at 8:35 AM, Arun Ranganathan <arun@mozilla.com> wrote:
>> On Aug 22, 2013, at 12:07 PM, Jonas Sicking wrote:
>>
>>> 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'd really like other implementors to weigh in before we remove Partial Blob Data.  Cc'ing folks who helped with it.
> Eric Urhane asked me to follow up on this thread on behalf of Gregg
> Tavares who unfortunately left Google.
>
> The current spec for partial blob data is too inefficient, because it
> accumulates all of the data since the beginning of the download. This
> is not what's desired for streaming downloads of large data sets.
> What's needed is a way to retrieve the data downloaded since the last
> query. Several web developers have asked about this recently as
> they're trying to stream ever larger 3D data sets into the browser.
>
>
>>> 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".
>>
>> I agree that we should do a better way.
> Agreed. It would be really good to finally make progress in this area.
>
> It sounds like Microsoft's Streams API proposal at
> https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm or
> tyoshino's Streams with Promises propsal at
> http://htmlpreview.github.io/?https://github.com/tyoshino/stream/blob/master/streams.html
> are two leading contenders. I personally don't care which flavor is
> chosen so long as things move forward. Microsoft's proposal does seem
> more fully fleshed out. (At least, it contains fewer instances of the
> word "blah". :) )
>
> -Ken

-- 
jCore
Email :  avitte@jcore.fr
Peersm : http://www.peersm.com
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