Re: Files on IndexedDB

On Sun, Jun 2, 2013 at 5:02 PM, piranna@gmail.com <piranna@gmail.com> wrote:

> > The File API spec does allow browsers to store File by reference.
> >
> I thought so... that's the reason I was surprised when readed about
> implementors where doing otherwise and in fact didn't found anything
> about it on the spec.
>

Note that "by reference" means "store a pointer to the original data, which
only remains valid so long as the original data is unchanged".  It doesn't
mean "store the filename and allow accessing the most recent data in the
file".  All I mean is that there are things browsers can do other than
making a pessimistic deep copy of the whole file.  The spec specifically
means to avoid that, since clearly making a deep copy of a large file isn't
acceptable (and I'm very surprised if browsers are naively doing that).


> > Note that there's one limitation to keep in mind.  File is meant to
> > represent a snapshot of the file at the time the user gave them to the
> site,
> > rather than the latest copy.  That is, if you store a File object in
> > something like IDB, and the user changes the file, the next time the
> site is
> > loaded it should either see a copy of the file as it was before, or get
> an
> > error, not see the user's changes.  This is meant as a security measure;
> the
> > idea is that a user giving a file to a site may not expect that he's
> giving
> > access to that file, and all future changes, for all time, and that
> > expecting users to manually revoke access to files somehow isn't
> reasonable.
> >
> > This is represented by the "snapshot state" concept.
> > http://dev.w3.org/2006/webapi/FileAPI/#snapshot-state-section
> >
> In fact, this can be seen both ways, just a snapshoot or a live
> update...
>

The spec says:

"Each Blob must have a snapshot state, which must be initially set to the
state of the underlying storage, if any such underlying storage exists."

"NotReadableError If the snapshot state of a File or a Blob does not match
the state of the underlying storage [...]"

The snapshot state is set to the initial state of the underlying storage
(eg. the initial data).  If the current state of the file is not the same
as it was when the Blob/File was first created, reads to it fail with
NotReadableError.

I don't think this can be reasonably interpreted as allowing live updates.

(The precise definition of "snapshot state" is left to the browser.
Ideally, it would mean "the contents of the file", but that's not possible
to do efficiently in most filesystems.  In practice, it's expected to mean
something like "the mtime of the file is unchanged".  Maybe this could use
some more non-normative explanation in the spec.)


> From my point of view, if an app want just a file particular
> version (a snapshoot, by instance), it would directly copy and/or
> upload it, and if it wants to get the updated version, it would get
> the reference and being aware of this particular case.
>

Like I said in my first message, this is to address a security concern.
Since it's for security reasons, telling site authors to do it themselves
rather misses the point :)

-- 
Glenn Maynard