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<a...@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 :avi...@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 : avi...@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
