W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

Re: File API: Blob and underlying file changes.

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 1 Feb 2010 14:22:46 -0800
Message-ID: <63df84f1002011422s525d1a24x47d3cca211860783@mail.gmail.com>
To: Dmitry Titov <dimich@chromium.org>
Cc: public-webapps@w3.org
On Mon, Feb 1, 2010 at 12:27 PM, Dmitry Titov <dimich@chromium.org> wrote:
> Basically, it's app-specific choice. It appears that the
> following implementation goes along with the current edition of the spec but
> also provides the ability to detect the file change:
> 1. File derives from Blob, so there is a File.size that performs synchronous
> file I/O. Not ideal, but easy to use and compatible with current forms
> upload.
> 2. File.slice() also does a synchronous IO and captures the current size and
> modification time of the underlying file - and caches it in the resulting
> Blob.

Note that the synch IO is not required by the spec. You can just cache
the filesize when the File object is created, which always happens
asynchronously. Then used that cached value through all calls to
File.size and Blob.slice().

> 4. In xhr.send() and FileReader, if the UA discovers that the underlying
> file is changed, it behaves just like when other file errors are discovered
> - returning 'error' progress event and setting FileReader.error attribute
> for example. We might need another FileError code for that if existing ones
> do not feel adequate.

This is definitely an interesting idea, possibly even something that
we should standardize. I don't really feel strongly either way, though
I am curious about platform support if the file lives in NFS or samba
or some such.

> One obvious difficulty here is the synchronous file IO on File.size and
> File.slice(). Trying to eliminate it requires some complexity in API that is
> not obviously better.

See above.

/ Jonas
Received on Monday, 1 February 2010 22:23:39 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:22 UTC