W3C home > Mailing lists > Public > public-device-apis@w3.org > March 2010

Re: New draft of FileWriter API posted

From: Mike Clement <mikec@google.com>
Date: Mon, 8 Mar 2010 18:30:59 -0800
Message-ID: <3ecc8b3f1003081830v59c7c7cdmdfbd9197f93abd7d@mail.gmail.com>
To: public-device-apis@w3.org
This is starting to look very useful.  I do have a couple of questions/comments:

1)  It might be useful for the FileWriter::write method to return the
number of bytes written so that it more closely matches other common
file APIs (e.g., fwrite).  Of course that value is often only used for
detecting the error of "not writing as many bytes as expected", which
I assume in FileWriter will cause an explicit onerror() invocation.
It still might be useful for statistics gathering and/or logging,

2)  I agree with the comment by annevk@opera.com that BlobBuilder
should have overloaded append() methods.  In fact, I believe that
BlobBuilder needs more functionality in this regard, especially when
it comes to getting non-textual data into a Blob.  It looks like
appendBlob() is meant to address the need of acquiring binary data,
but it's looking to me that the only way to get binary data into a
Blob in the first place is by reading it from a file.  One can easily
imagine a scenario where you have an image element (JPG) and want to
put its bytes into a Blob and save it out to a file.  It would be
inefficient to require the data to be encoded into a string just to
save it out, but I don't see another pathway right now.  Are there
other Blob acquisition/manipulation techniques out there that I'm
missing?  I guess what I'm saying is that I might want to capture any
number of interesting elements as binary data and save them to disk,
but it's unclear to me whether or not the browser development
community is embracing the concept of the Blob as a first class
citizen such that I can expect to access elements as binary where
those sources are binary to begin with (e.g., images, video, audio).

Looking forward to more File API developments!

Received on Wednesday, 10 March 2010 09:20:38 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:42 UTC