- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 15 Jan 2010 10:36:25 -0800
- 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 UTC