[Bug 17746] New: Specify Blob snapshots more robustly

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

           Summary: Specify Blob snapshots more robustly
           Product: WebAppsWG
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: File API
        AssignedTo: arun@mozilla.com
        ReportedBy: arun@mozilla.com
         QAContact: public-webapps-bugzilla@w3.org
                CC: public-webapps@w3.org, glenn@zewt.org


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

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Wednesday, 11 July 2012 19:58:28 UTC