Glenn,
On May 22, 2012, at 11:48 AM, Glenn Maynard wrote: > On Tue, May 22, 2012 at 1:41 AM, Kinuko Yasuda <[email protected]> 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 >
