Re: [File API] File behavior under modification

Glenn,


On May 22, 2012, at 11:48 AM, Glenn Maynard wrote:

> On Tue, May 22, 2012 at 1:41 AM, Kinuko Yasuda <kinuko@google.com> wrote:
> In my understanding WebKit's behavior is querying the metadata / reading the content as lazy as possible, partly because the spec was/is ambiguous (especially about when the file metadata should be captured) and also we didn't want to break existing Web applications.
> 
> But the synchronicity of the current .size, .modificationTime and .slice() implementation has been a big headache and I'm all happy if we can make the behavior clearer.
> 
> The whole point of the Blob API is to never, ever do file I/O synchronously in the UI thread.  (I think the "read into memory at the time a read operation is initiated" bit is what's confusing things.  I don't think it was intended to mean "take the snapshot at the first read operation", but that's what it sounds like.)  Some other issues:
> 


<snip />


> - The access restrictions applied to File also need to be clearly applied to Blobs created with slice().
> - "modified on disk since the File object reference is created" seems incorrect.  If you structured clone a File (eg. postMessage), you create a new File object.  That shouldn't "refresh" the snapshot; you should still only be able to access the file as it was when you received the *original* File.
> 
> I'd suggest defining this more precisely, and at the level of Blob.  Here's an attempt:
> 
> - In section 6, add: "Each Blob has a snapshot state, which is initially set to the state of the underlying storage.  Note: this value is preserved through structured clone."
> - Also in section 6, add: "If, at the time of any read operation on the Blob, the state of the underlying storage containing the Blob is not equal to snapshot state, the read must fail with a NotReadableError."
> - In 6.3.2. The slice method, add: "Let the snapshot state of A be the snapshot state of O."  (This means the snapshot state follows through slices.)
> - In 7.1, remove "For synchronous reads ...".  The requirement to fail is now defined by section 6, and the way it fails (passing on the NotReadableError or an error event) should be defined by the associated read operation.
> 
> This stores a conceptual snapshot of the underlying storage at the time the Blob (or File) is created.  The "snapshot state" is purely conceptual, representing the logical underlying snapshot that the Blob represents.  If it represents a file on disk, and the file changes (or is deleted), it has a new snapshot state.
> 
> This approach puts the requirement at the Blob level.  For Blobs whose underlying storage can never be modified (regular, old-fashioned blobs), it has no effect, since the snapshot state never changes.  The snapshot is made when the a Blob (or File) is constructed, except for slice() and structured clone, which copy the source object's state.
> 


These are really solid proposals, and I've filed Bug 17746 to keep track of this.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17746

-- A*

> -- 
> Glenn Maynard
>