Overlap between StreamReader and FileReader -[Re: File API - Progress - Question about Partial Blob data]

Redirecting this thread to the "overlap..." thread because it is the same.

For Cyril --> I think the mistake is that XHR does provide incremental 
data on 'loading' instead of delta data.

I have read again: 
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0727.html.

And still do not get it quite well, especially the presence of 
eventtarget, as if for example the API was supposed to be able to 
predict the end of a stream.

Again, I don't think that's the job of the API, its only job is to be 
able to provide delta data, then the user implementation takes care of 
the rest.

I read again too 
https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm. This is 
about the same as the File API.

Then I tried to figure out what would be the use of a Stream and came up 
with the following examples:

var stream=new Stream();
document.getElementById('video').src=URL.createObjectURL(stream);

var ws=new WebSocket(xxx);
ws.onmessage=function(evt) {
     stream.append(evt.data)
     //or calculate the hash of the stream using delta data
     //or encrypt the stream using delta data
     //etc
};

or

var xhr_object = new XMLHttpRequest();
xhr_object.open("GET","yyy",true);
client.responseType="stream";
xhr_object.onreadystatechange=function() {
     if (xhr_object.readyState===3) {
         stream.append(this.deltaresponse);
         //or same as above
     };
};
xhr_object.send();

or

var pc = new RTCPeerConnection(xxx);
pc.onaddstream = function(evt){
     stream.append(evt.stream);
     //or same as above
}

//Stream to ArrayBuffer
var arraybuffer;
stream.readBinary().then(function(response) {
     arraybuffer=response;
     //we should be able here to read the stream per blocks of a given 
size so we don't have to reslice the entire result to process it
     //not sure how this can be speced with promises...
});

So unless there are some use cases that are not similar to the above 
examples, maybe the Streams API should just be something like:

partial interface Blob {
   Promise<ArrayBuffer> readBinary(BlobReadParams); (+block option)
   Promise<DOMString> readText(BlobReadTextParams); (+block option)
};

interface Stream : Blob {
   Promise<Stream> append(ArrayBufferView or Stream or MediaStream or 
Blob or ...);
};

and XHR is modified to add a property returning delta data.

Regards,

Aymeric


Le 05/09/2013 14:43, Cyril Concolato a écrit :
> Hi all,
>
> Le 29/08/2013 01:25, Aymeric Vitte a écrit :
>> 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)
> I fully agree with Aymeric. Can someone summarizes what's the history 
> behind XHR that makes it hard to change (or better give an example 
> that would break)?
>
> I would like to see progress on the Stream API (how can I help?) 
> because it solves one use case on which I'm working: download and 
> aggregation of resources via XHR and in parallel use of the 
> aggregation via a media element. This is similar to the MediaSource 
> approach but for simpler progressive download cases. This is a bit 
> different from the use cases I've seen on this list. The data is not 
> consumed by JavaScript calls but by the browser directly. The JS would 
> just use a series of StreamBuilder.append calls.
>
> Cyril
>
>>
>> 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
>
>

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

Received on Monday, 9 September 2013 09:52:20 UTC