W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: File API Feedback

From: Nigel Tao <nigel.tao.gnome@gmail.com>
Date: Mon, 27 Jul 2009 22:38:06 +1000
Message-ID: <9188fcea0907270538j5cee5225ucffe5a8d2d3c9d5@mail.gmail.com>
To: arun@mozilla.com
Cc: public-webapps@w3.org
2009/7/22 Arun Ranganathan <arun@mozilla.com>:
> So, currently, we provide a fileData.getAsText(fileCallback, encoding,
> error)
>
> and
>
> within fileCallback (a callback function) you can get the file's data as a
> string (say a UTF-8 encoded string, or any encoding specified by
> "encoding"); it is passed as an argument to fileCallback.
>
> Then, you can append to the string (or prepend, in the case of the header)
> using the standard JavaScript string methods.  And you can, of course, post
> the string via XHR.
>
> Along with a similarly asynchronous splice method to generate "ranged"
> subsets of a FileData object, I think that we've got *most* of the features
> exposed by both BlobBuilder and Blob.
>
> Have I missed something important?


I'm jumping in late to the mailing list, so I might have missed
something said earlier...

What happens if you call fileData.getAsText on a file whose contents
are not valid unicode text (either UTF-8, UTF-16, or some other
encoding)? For example, I presume that a significant fraction
JPEG-encoded images aren't valid UTF-8. None of the three FileError
codes (NOT_FOUND_ERR, NOT_READABLE_ERR, SECURITY_ERR) seem to apply.

Or am I just fundamentally confused, and is a DOMString not
necessarily valid unicode?
Received on Tuesday, 28 July 2009 08:43:10 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:33 GMT