- From: Cyril Concolato <cyril.concolato@telecom-paristech.fr>
- Date: Thu, 05 Sep 2013 14:43:27 +0200
- To: public-webapps@w3.org
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 -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Multimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.wp.mines-telecom.fr/
Received on Thursday, 5 September 2013 12:43:38 UTC