Re: [w3c/FileAPI] Define WebKit's underlying file changes behavior (#47)

If I understand this issue it is more about better defining what happens if the [snapshot state](https://w3c.github.io/FileAPI/#snapshot-state) of a blob/file no longer matches the file on disk, rather than trying to actually support files that change. I.e. the spec currently sort of hand-wavily describes that attempting to read such a blob should [throw a NotReadableError](https://w3c.github.io/FileAPI/#SnapshotStateFR), but that isn't actually reflected in the reading algorithms.

Not sure if changing attributes of the File/Blob objects themselves makes sense... Unfortunately there are cases in blink were currently we don't really deal with snapshot states correctly, and can have file.size change from under you, but I would consider all of those things bugs.

Not sure if I'm a fan of introducing "changed" events either... I like the conceptual simplicity of a Blob/File object being immutable. Sure, reading might fail because the snapshot state became invalid, but otherwise a blob/file always represents the same data as it did when it was first created.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/FileAPI/issues/47#issuecomment-389577518