Re: File API: Blob and underlying file changes.

So it seems there is 2 ideas on how to handle the underlying file changes in
case of File and Blob objects, nicely captured by Arun above:

1. Keep all Blobs 'mutating', following the underlying file change. In
particular, it means that Blob.size and similar properties may change from
query to query, reflecting the current file state. In case the Blob was
sliced and corresponding portion of the file does not exist anymore, it
would be clamped, potentially to 0, as currently specified. Read operations
would simply read the clamped portion. That would provide similar behavior
of all Blobs regardless if they are the Files or obtained via slice(). It
also has a slight disadvantage that every access to Blob.size or
Blob.slice() will incur synchronous file I/O. Note that current
File.fileSize is already implemented like that in FF and WebKit and uses
sync file I/O.

2. Treat Blobs that are Files and Blobs that are produced by slice() as
different blobs, semantically. While former ones would 'mutate' with the
file on the disk (to keep compat with form submission), the later would
simply 'inherit' the file information and never do sync IO. Instead, they
would fail later during async read operations. This has disadvantage of Blob
behaving differently in some cases, making it hard for web developers to
produce correct code. The synchronous file IO would be reduced but not
completely eliminated, because the Blobs that are Files would continue to
'sync' with the underlying file stats during sync JS calls. One benefit is
that it allows detection of file content change, via checks of modification
time captured when the first slice() operation is performed and verified
during async read operations, which provides a way to implement reliable
file operations in face of changing files, if the developer wants to spent
an effort to do so.

It seems folks on the thread do not like the duplicity of Blobs (hard to
program and debug), and there is also a desire to avoid synchronous file IO.
It seems the spec today leans more to the #1. The only problem with it is
that it's hard to implement some scenarios, like a big file upload in chunks
- in case the file changes, the result of upload may actually be a mix of
new and old file contents and there is no way to check... Perhaps we can
expose File.modificationTime? It still dos not get rid of sync I/O...

Dmitry

On Fri, Jan 15, 2010 at 12:10 PM, Dmitry Titov <dimich@chromium.org> wrote:

> On Fri, Jan 15, 2010 at 11:50 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>
>>
>> This doesn't address the problem that authors are unlikely to even
>> attempt to deal with this situation, given how rare it is. And even
>> less likely to deal with it successfully given how hard the situation
>> is reproduce while testing.
>
>
> I don't know how rare the case is. It might become less rare if there is an
> uploader of big movie files and it's easy to overwrite the big movie file by
> hitting 'save' button in movie editor while it is still uploading... Perhaps
> such uploader can use other means to detect the file change though...
>
> It would be nice to spell out *some* behavior though, or we can end up
> with some incompatible implementations. Speaking about Blob.slice(), what is
> recommended behavior of resultant Blobs on the underlying file change?
>
>
>
>
>> / Jonas
>>
>
>