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 or Blob that has been read into memory currently; when processing the > read method readAsText, partial Blob data is a DOMString that is incremented > as more bytes are loaded (a portion of the total) [ProgressEvents], and > when processing readAsArrayBuffer partial Blob data is an ArrayBuffer > [TypedArrays] object consisting of the bytes loaded so far (a portion of the > total)[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. -- A*
