Re: Files on IndexedDB
On Sun, Jun 2, 2013 at 5:50 PM, pira...@gmail.com wrote: > 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... > Sorry, I don't know about Chrome's current behavior. This would be pretty easy to test; look at the link count on the file. (I'd be surprised if they were using hard links.) 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... > That sounds more like a simple bug/incomplete implementation than a liberal interpretation. If lastModifiedDate or length are null, that's definitely a bug (neither one is nullable). Yep :-) So, what other solution would be feasable? Both behaviours > (inmutable and live files) seems to be valid for some use cases... > File objects aren't appropriate for live file updates, as Sicking said elsewhere. (If I had a nicer solution I'd have proposed it already...) -- Glenn Maynard
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
Re: Files on IndexedDB
On Sun, Jun 2, 2013 at 5:02 PM, pira...@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
Fwd: 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 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... 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. > The difficulty is that most filesystems don't support lightweight snapshots > of files. Making a deep copy is one way to implement this, but painfully > inefficient for large files. Storing the file's modification time with the > snapshot, and using it to determine if the file has been changed, should be > a close enough approximation to address the security concerns. The spec > allows this (it leaves the specifics of the "state of the underlying > storage" as an implementation detail). > > I don't know if there are other IndexedDB-specific issues (not familiar with > that API). > I don't remember to read about them, or at least my interpretation give me to think there was no problems and Files and Blob objects would be added as references. In fact, I remember to read some months ago that Firefox was storing Files and Blobs directly on hard disk files on a hidden folder, only that now I'm not sure if user specified files are being directly specified (that I believe it's the good way to do it) or are being previously being copied inside this hidden folder (storing a particular copy, but also wasting a lot of hard disk space, and also don't allowing to have references inside IndexedDB for "live files", that's what I'm interested for). -- "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
Re: Filesystem events
> We didn't come to much of a resolution. > It was suggested that the current behavior in browsers was incorrect; that > the File should become inaccessible if/when it changes. > > I disagree, the fact that re-accessing a file object loads the > latest version of the file is a valuable feature IMO, even if it was not > intentional. I don’t know if preventing that is what you meant, but further > to require that the user reselect a file if it has changed would be a UX > killer. > I agree, as I said, I find this behaviour fairly better and useful. -- "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
Re: Filesystem events
> It was suggested that the current behavior in browsers was incorrect; that > the File should become inaccessible if/when it changes. > As I put on another thread, if an app want a particular version of a file (a snapshoot) it should copy and/or upload it, and if it want a "live file", just keep the reference and be aware of it, both checking the modificationTime or better listening to an event (File.onchange? File.onupdate?) > I don't know that we've made it any further on the concept of mount points > and/or simple input file directory standardization, and as such, there's not > been progress on > file / directory watchers. > I'm really interested on this :-D I believe both the Device Storage API and the Filesystem API could be capable of this in a safe way, maybe with little modifications. For example, Input tag have an "entries" attribute on Chrome (although currently not working...) so when you select a directory you can run over it using the Filesystem API, it only keeps some way to store it so it can be accesed later (storing the DirEntry inside IndexedDB the same way a FileList would be really cool...). This way you could have some kind of "user selected Filesystems". On the other hand, Device Storage API on Firefox with navigator.getDeviceStorage(directory) only allow some system pre-defined directories. If it could be possible to add some user defined per-webapp directories (for example from an Input tag and something like navigator.addDeviceStorage(name, dirEntry) ) it would expand it's functionality a lot. I dislike the API because being too primitive, but both ones goes in the right direction, just they need a method so user add a DirEntry or FileList object and store it named in the browser, no more. -- "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
Re: [XHR] anonymous flag
Den 1. juni 2013 kl. 10:14 skrev Anne van Kesteren : > On Thu, May 30, 2013 at 1:30 PM, Hallvord Reiar Michaelsen Steen > wrote: >> So creating a new tri-state property in the XHR spec should also simplify >> integration with the Fetch spec. > > Agreed. The question is, if we take it as a given that we're going to > get a new API (that uses futures, deals with tainted requests, etc.) > is it worth expanding the older API too? It will not come as a surprise to you that I vote "yes" to this question, but let me try to add some reasoning: * From a developer point of view, I doubt it will matter very much, but it seems that we should fix the older API. There is known demand for the "non-credentials request to origin server" use case, and the spec already serves it in a somewhat messy way. If we leave the spec as it is, developers risk having to implement the messy way first and later a cleaner way for Fetch (while having to keep supporting the messy way for legacy content? The web rarely forgets your spec mistakes once implemented..) * It could be considered a "selling point" for the new API, but it's not a big one. What you quote above, futures and such, are big selling points. This doesn't make the list. * Given that it's not a selling point, I think consistency from the old to the new API is more important to normal developers. If you do not fix the old API we risk fielding questions like "Wot? Where did my anonymous mode go?" and for a feature that may have security implications, causing developer confusion is certainly not a good idea. That's my 5 cents as of this Sunday evening.. Hallvord R
