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

Re: File API: Blob and underlying file changes.

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 15 Jan 2010 10:36:25 -0800
Message-ID: <63df84f1001151036r25894a65vbd2feafbc7bcf753@mail.gmail.com>
To: Dmitry Titov <dimich@chromium.org>
Cc: Darin Fisher <darin@chromium.org>, Jian Li <jianli@chromium.org>, Chris Prince <cprince@google.com>, arun@mozilla.com, Web Applications Working Group WG <public-webapps@w3.org>
On Fri, Jan 15, 2010 at 10:19 AM, Dmitry Titov <dimich@chromium.org> wrote:
> Nobody proposed locking the file. Sorry for being unclear if that sounds
> like it. Basically it's all about timestamps.
> As Chris proposed earlier, a read operation can grab the timestamp of the
> file before and after reading its content and throw exception if the
> timestamps do not match. This is pretty good approximation of 'atomic' read
> - although it can not guarantee success, it can at least provide reliable
> detection of it.

I don't understand how you intend to use the timestamp. Consider the
following scenario:

1. User drops a 10MB File onto the a page.
2. Page requests to read the file using FileReader.readAsBinaryString
and installs a 'progress' event listener.
3. Implementation grabs a the current timestamp and then starts reading the file
4. After 2MB of data is read the implementation updates
FileReader.result with the partial read and fires a 'progress' event.
5. Page grabs the partial result and processes it.
6. After another 1MB of data is read, but before another 'progress'
event has been fired, the user modifies the file such that the
timestamp changes
7. The implementation detects that the timestamp has changed.

Now what?

You can't "throw an exception" since part of the file has already been
delivered. You could raise an error event, but that's unlikely to be
treated correctly by the page as this is a very rare condition and
hard to test for, so the page author has likely not written correct
code to deal with it. It's additionally not atomic since the read
started, but was interrupted.

/ Jonas
Received on Friday, 15 January 2010 18:37:22 GMT

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