Re: Files on IndexedDB

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

I see.


> 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).
>
I agree, it makes sense, only that I have read contradictory info
regarding to actual implementations. Maybe they are doing hard links
instead plain copies, and that's the source of the confusion? This
would be acceptable, although not all OSes or filesystems can do
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.
>
Then Chrome is taking REALLY liberally the interpretation, because on
some tests I removed the file and instead of raising an error it just
gave me an empty content and null modifiedTime and lenght...


> (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.)
>
Maybe that's related with the behaviour of Chrome I've described?


>> 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 :)
>
Yep :-) So, what other solution would be feasable? Both behaviours
(inmutable and live files) seems to be valid for some use cases...


--
"Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton de sitios diferentes, simplemente escribe un sistema operativo
Unix."
– Linus Tordvals, creador del sistema operativo Linux

Received on Sunday, 2 June 2013 22:51:12 UTC