- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 23 Jan 2012 01:02:09 -0800
- To: Glenn Maynard <glenn@zewt.org>
- Cc: Eric U <ericu@google.com>, Webapps WG <public-webapps@w3.org>, Jian Li <jianli@chromium.org>
On Sun, Jan 22, 2012 at 7:10 AM, Glenn Maynard <glenn@zewt.org> wrote:
> On Sun, Jan 22, 2012 at 12:57 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> myFileEntry.createWriter(function(mywriter) {
>> // write some data
>> mywriter.write(someblob);
>> // wait for "success"
>> mywriter.onwrite = function() {
>> // Read some data;
>> reader = new FileReader;
>> reader.readAsArrayBuffer(mywriter.file);
>> // wait for "success"
>> reader.onload = function() {
>> // do something with read data
>> }
>> };
>> });
>>
>> This is pretty hideous though, but as far as I can tell better than
>> what we have now. But it is very surprising to have a File accessor on
>> the FileWriter.
>
>
> Is the above meant to lock myFileEntry for the entire operation, starting
> when the function(mywriter) callback starts and ending with reader.onload?
Yes. How exactly it works is something that is being discussed in this
very thread. The idea discussed so far is to have an explicit
FileWriter.close() call which would release the lock. The lock would
also be released when the FileWriter is GCed.
>> think the main problem is that reading and writing is spread out
>> over two separate objects. I can't think of a way to make things look
>> good as long as that is the case. Maybe the solution is to add
>> readAsArrayBuffer/readAsText/readAsDataURL directly on FileWriter?
>
> Could FileWriter inherit from FileReader (and FileWriterSync from
> FileReaderSync)?
That wouldn't make much sense since FileWriter is tied to a specific
file, whereas the functions on FileReader is passed the file to read
as an argument.
> There's an underlying issue to this, though. It only allows a single object
> to access the file. (Putting read access on FileWriter--turning it into
> something like FileReadWriter--is just a workaround for that issue.) This
> could bite the platform later on; it doesn't allow any other API that
> accesses File data to coexist and use the same locking mechanism.
>
> The more familiar approach would be to lock Entry (analogous to locking the
> file itself), and then allowing any API to access the Entry in that thread.
This is definitely an interesting idea.
/ Jonas
Received on Monday, 23 January 2012 09:03:13 UTC