Re: [File API] File behavior under modification

On Wed, May 23, 2012 at 12:48 AM, Glenn Maynard <glenn@zewt.org> 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.
>

Apparently this point wasn't initially addressed very well in the API,
which has been causing a confusion, but we could make it clear it'd be nice.


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

Agreed, this sentence is confusing.  This sounds like when we should take a
snapshot is not necessarily tied with the creation time of the File object.

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

Just to make sure, I assume 'the underlying storage' includes memory.

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


We should also make it clear whether .size and .lastModifiedDate should
return live state or should just returning the same constant values.  (I
assume the latter)

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