Le 21/08/2013 16:16, Arun Ranganathan a écrit :
On Aug 20, 2013, at 7:13 PM, Aymeric Vitte wrote:
The specs says :
" It can also return /partial Blob data/. Partial Blob data is the
part of the |File| <http://www.w3.org/TR/FileAPI/#dfn-file> or |Blob|
<http://www.w3.org/TR/FileAPI/#dfn-Blob> that has been read into
memory /currently/; when processing the read method
<http://www.w3.org/TR/FileAPI/#read-methods> |readAsText|
<http://www.w3.org/TR/FileAPI/#dfn-readAsText>, partial Blob data is
a |DOMString| that is incremented as more bytes are |loaded| (a
portion of the |total|) [ProgressEvents
<http://www.w3.org/TR/FileAPI/#ProgressEvents>], and when processing
|readAsArrayBuffer|
<http://www.w3.org/TR/FileAPI/#dfn-readAsArrayBuffer> partial Blob
data is an |ArrayBuffer| [TypedArrays
<http://www.w3.org/TR/FileAPI/#TypedArrays>] object consisting of the
bytes |loaded| so far (a portion of the |total|)[ProgressEvents
<http://www.w3.org/TR/FileAPI/#ProgressEvents>]. The list below is
normative for the |result| attribute and is the conformance criteria
for this attribute"
What is the rationale for that? The result attribute should better
contain for progress events the latest data read and not the data
read from the begining that you could easily reconstitute while the
contrary requires more work.
Use case: calculate the hash of a file while you are reading it.
The ask for "deltas" to be sent with progress notifications came up on
this listserv before -- see the thread starting at
http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0069.html
I agree that the deltas model is also useful, but you can see there's
some implementation history with XHR here as well. The use case is to
receive the file bits as they are constituted from the read (just as
with an HTTP request, where you get the bits "so far" till the rest
are constituted).
A good way to solve the use case of meaningful deltas might be with
the Streams API, still TBD.
PS: I did not test it in all browsers, but unless I am using it
wrongly, the result attribute is always null for progress events.
But not null for the onload ? In many cases, a progress might not
fire, depending on file size.
No, only for progress, which does fire for files of several MB.
I don't know about the XHR history but what is the use case of
incremented data (which is not implemented currently)?
-- A*
--
jCore
Email : [email protected]
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
