Re: Colliding FileWriters

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?
 A useful locking mechanism would need to be able to do that (lock for a
series of reads and writes), but I don't see how that could happen
here--onwrite and onload are called after the outer callback has returned.

FWIW, I don't think it's strange to be able to query the underlying File
from a FileWriter.  If File objects become inaccessible when the file has
changed (discussed in the "File modification" thread), then it's
particularly useful: the File accessor of FileWriter would give you a File
updated to access the latest version of the File after changing it with
FileWriter.  Since the FileWriter knows what it's done to the file (at
least while access is exclusive), it can create a File without having to
hit the disk.  (Maybe.  I'm not sure if it can correctly fill
in lastModifiedDate without doing a stat() to see what mtime was actually
used...)

Having to recreate File after writing with FileWriter isn't very intuitive,
but as long as File inherits from the immutable Blob interface, it seems
inherent.

>  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)?

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.
 That approach probably raises deadlock issues if multiple Entries can be
locked, though.  (I'm not sure that any method avoids that with the sync
API, though.  Even if you only allow locking one Entry at a time--a harsh
restriction--you could still get deadlocks by combining it with locking
calls from other APIs.)

-- 
Glenn Maynard