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<[email protected]> 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 :[email protected]
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/
