W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: [File API] About Partial Blob Data

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 18 Jan 2013 02:14:45 -0800
Message-ID: <CA+c2ei_gSiSznY2L09TcBToPjr0kbjyP854TtESefYwcn9VLGA@mail.gmail.com>
To: Cyril Concolato <cyril.concolato@telecom-paristech.fr>
Cc: public-webapps@w3.org
On Thu, Jan 17, 2013 at 1:56 AM, Cyril Concolato
<cyril.concolato@telecom-paristech.fr> wrote:
> Hi all,
> Reading the File API, it is not clear to me what the behavior is when
> reading partial Blob data. The spec says:
> " 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]. "
> Does this mean that the result object is the same or it is a new object each
> time there is a progress event ? In the case of a DOMString, it could be the
> same object incremented but if it is an ArrayBuffer, since it is immutable,
> it cannot be incremented.

Strings in JS are immutable. So it will always be a new string.

> So in the case the final length of the Blob is not
> known yet (e.g. chunked XHR), result has to be a new object each time. Am I
> wrong here? If not, could you clarify the spec ?

The size of a Blob is always known. The .size property never returns
'undefined' or 'null' or anything like that. XHR never returns a Blob
object until it knows what size of Blob object to create.

/ Jonas
Received on Friday, 18 January 2013 10:15:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:58 UTC