Re: [File API] File behavior under modification

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:

- 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.

-- 
Glenn Maynard