Re: File modification
On 1/12/12 12:53 PM, Arun Ranganathan wrote: Oh I'm glad to see this one! Is it Blob and File that can be put into IDB? How do I create a new File (with a name field) from a Blob? Charles: see the thread on making Blobs constructable -- follow http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0439.html http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0918.html Seems like the consensus was to stay away from Blob to File methods. FileEntry and [a download] being the heirs apparent. Well, the consensus was to introduce a constructor to Blob, which I'm about to do :) The File API specification should do a better job describing what happens to a File if the underlying resource changes. We use the word immutable, but I think we have to make this substantially clearer. My take on a File object that's been modified is that the file no longer exists. User agents MUST process reads on files that no longer exist at the time of read as errors A file may change on disk since the original file selection, thus resulting in an invalid read. Just to be clear, disappearing a file from FileList might is the same as item(index) returning null for the the index'th item. Maybe this should be enforced as well for any kind of modification? This isn't what Fx does today. -- A*
Re: File modification
On 1/13/12 11:13 AM, Arun Ranganathan wrote: On 1/12/12 12:53 PM, Arun Ranganathan wrote: Oh I'm glad to see this one! Is it Blob and File that can be put into IDB? How do I create a new File (with a name field) from a Blob? Charles: see the thread on making Blobs constructable -- follow http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0439.html http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0918.html Seems like the consensus was to stay away from Blob to File methods. FileEntry and [a download] being the heirs apparent. Well, the consensus was to introduce a constructor to Blob, which I'm about to do :) Sorry, I misread that thread; and misremembered it. I saw it as appending multiple strings. I'm happy to see the Blob constructor happening! The File API specification should do a better job describing what happens to a File if the underlying resource changes. We use the word immutable, but I think we have to make this substantially clearer. My take on a File object that's been modified is that the file no longer exists. User agents MUST process reads on files that no longer exist at the time of read as errors A file may change on disk since the original file selection, thus resulting in an invalid read. Just to be clear, disappearing a file from FileList might is the same as| item(index) |returning null for the the index'th item. Maybe this should be enforced as well for any kind of modification? This isn't what Fx does today. I'm fine with that being the defined behavior for FileList when implementations have elected to remove modified files. It's still optional: implementations MAY remove modified files from the FileList, those that do MUST return null for the index'th item. I'm hoping they don't go down that route. It may mean a disconnect between the results of submitting a post and the files available to the scripting environment. Again, I don't imagine that input type=file and a subsequent .submit() would result in an empty POST when the user modifies the underlying file. Though it should do so if the user deletes or renames the underlying file. I suppose things could get nasty, though, if the user modifies the file while the post is happening. I don't want to think about those kind of race conditions. Hopefully the UA can put a temporary write lock on those files. Well... I'm satisfied on this topic. I think we've incrementally improved what the File API will specify. -Charles
Re: File modification
That would be bad; it would require null checks that people would forget to perform due to the rarity of the condition. Instead, it should return a File that fails when read attempts are made. (Of course, those errors are also rare, but it's at least not adding a *new* rare case.) On Jan 13, 2012 12:13 PM, Arun Ranganathan aranganat...@mozilla.com wrote: On 1/12/12 12:53 PM, Arun Ranganathan wrote: Oh I'm glad to see this one! Is it Blob and File that can be put into IDB? How do I create a new File (with a name field) from a Blob? Charles: see the thread on making Blobs constructable -- follow http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0439.html http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0918.html Seems like the consensus was to stay away from Blob to File methods. FileEntry and [a download] being the heirs apparent. Well, the consensus was to introduce a constructor to Blob, which I'm about to do :) The File API specification should do a better job describing what happens to a File if the underlying resource changes. We use the word immutable, but I think we have to make this substantially clearer. My take on a File object that's been modified is that the file no longer exists. User agents MUST process reads on files that no longer exist at the time of read as errors A file may change on disk since the original file selection, thus resulting in an invalid read. Just to be clear, disappearing a file from FileList might is the same as item(index) returning null for the the index'th item. Maybe this should be enforced as well for any kind of modification? This isn't what Fx does today. -- A*
Re: File modification
On Wed, Jan 11, 2012 at 12:35 PM, Charles Pritchard ch...@visc.us wrote: On 1/11/2012 12:27 PM, Eric U wrote: On Wed, Jan 11, 2012 at 12:22 PM, Charles Pritchardch...@jumis.com wrote: On 1/11/2012 9:00 AM, Glenn Maynard wrote: This isn't properly specced anywhere and may be impossible to implement perfectly, but previous discussions indicated that Chrome, at least, wanted File objects loaded from input elements to only represent access for the file as it is when the user opened it. That is, the File is immutable (like a Blob), and if the underlying OS file changes (thus making the original data no longer available), attempting to read the File would fail. (This was in the context of storing File in structured clone persistent storage, like IndexedDB.) Mozilla seems to only take a snapshot when the user opens the file. Chrome goes in the other direction, and does so intentionally with FileEntry. I'd prefer everyone follow Chrome. We do so with FileEntry, in the sandbox, because it's intended to be a much more powerful API than File, and the security aspects of it are much simpler. When the user drags a File into the browser, it's much less clear that they intend to give the web app persistent access to that File, including all future changes until the page is closed. I don't think we'd rush to make that change to the spec. And if our implementation isn't snapshotting currently, that's a bug. In my reading of the spec, UAs explicitly instructed not to implement a snapshot. If so that's a bug in the spec. File and Blob objects are intended to contain constant data. For a file object returned from input type=file I would expect the implementation to make all reads fail if the data changes on disk. I know we don't do this in Firefox right now, but I consider that a bug. / Jonas
Re: File modification
Side-effects of event registration are outside of the DOM event model. UAs can do whatever transparent optimizations they want, of course, but APIs shouldn't *depend* on that for efficient implementations. Occasional polling definitely has significant overhead (directories may have tens of thousands of files, be on network shares, etc), and should be widely avoided. I also wonder whether change notifications work over eg. NFS. It would be bad if this feature only sometimes worked (especially if it breaks on major but less used configurations like NFS), since once deployed, apps will be designed around it. On Jan 11, 2012 12:22 PM, Charles Pritchard ch...@jumis.com wrote: On 1/11/2012 9:00 AM, Glenn Maynard wrote: This isn't properly specced anywhere and may be impossible to implement perfectly, but previous discussions indicated that Chrome, at least, wanted File objects loaded from input elements to only represent access for the file as it is when the user opened it. That is, the File is immutable (like a Blob), and if the underlying OS file changes (thus making the original data no longer available), attempting to read the File would fail. (This was in the context of storing File in structured clone persistent storage, like IndexedDB.) Mozilla seems to only take a snapshot when the user opens the file. Chrome goes in the other direction, and does so intentionally with FileEntry. I'd prefer everyone follow Chrome. The spec on this could be nudged slightly to support Chrome's existing behavior. From dragdrop: http://www.whatwg.org/specs/**web-apps/current-work/**multipage/dnd.htmlhttp://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html The files attribute must return a live FileList sequence http://www.whatwg.org/specs/**web-apps/current-work/** multipage/infrastructure.html#**livehttp://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#live If a DOM object is said to be live, then the attributes and methods on that object must operate on the actual underlying data, not a snapshot of the data. Dragdrop continues: for a given FileList object and a given underlying file, the same File object must be used each time. Given that the underlying file can change, and the FileList sequence is live, it seems reasonable that subsequent reads of FileList would access a different File object when the underlying file has changed. FileList.onchanged would be appropriate. File.onupdated would not be appropriate. Entry.onupdated would be appropriate. I have one major technical concern: monitoring files for changes isn't free. With only a DOM event, all instantiated Files (or Entries) would have to monitor changes; you don't want to depend on do something if an event handler is registered, since that violates the principle of event handler registration having no other side-effects. Monitoring should be enabled explicitly. I also wonder whether this could be implemented everywhere, eg. on mobile systems. At this point, iOS still doesn't allow input type=file nor dataTransfer of file. So, we're looking far ahead. A system may send a FileList.onchanged() event when it notices that the FileList has been updated. It can be done on access of a live FileList when a mutation is detected. It could be done by occasional polling, or it could be done via notify-style OS hooks. In the first case, there is no significant overhead. webkitdirectory returns a FileList object that can be monitored via directory notification hooks; again, if the OS supports it. Event handlers have some side effects, but not in the scripting environment. onclick, for example, may mean that an element responds to touch events in the mobile environment. -Charles
Re: File modification
On Jan 12, 2012, at 6:58 AM, Kyle Huey m...@kylehuey.com wrote: On Thu, Jan 12, 2012 at 3:45 PM, Glenn Maynard gl...@zewt.org wrote: FYI, I don't think this is clear for File from the spec. It's even more important if File objects are stored in History or IndexedDB; that it should be a *shallow* copy, with enough information stored to invalidate it if the underlying file changes, doesn't seem to be specified. (As far as I know, nobody implements that yet; being able to eg. retain open files in History states would be extremely useful. Gecko nightlies are capable of storing File objects in IndexedDB, We are doing deep copies (what is retrieved from the database is always a copy of the file as it was when it was placed in the database). Oh I'm glad to see this one! Is it Blob and File that can be put into IDB? How do I create a new File (with a name field) from a Blob? -Charles
Re: File modification
On 1/12/2012 12:30 AM, Jonas Sicking wrote: On Wed, Jan 11, 2012 at 12:35 PM, Charles Pritchardch...@visc.us wrote: On 1/11/2012 12:27 PM, Eric U wrote: On Wed, Jan 11, 2012 at 12:22 PM, Charles Pritchardch...@jumis.com wrote: On 1/11/2012 9:00 AM, Glenn Maynard wrote: This isn't properly specced anywhere and may be impossible to implement perfectly, but previous discussions indicated that Chrome, at least, wanted File objects loaded from input elements to only represent access for the file as it is when the user opened it. That is, the File is immutable (like a Blob), and if the underlying OS file changes (thus making the original data no longer available), attempting to read the File would fail. (This was in the context of storing File in structured clone persistent storage, like IndexedDB.) Mozilla seems to only take a snapshot when the user opens the file. Chrome goes in the other direction, and does so intentionally with FileEntry. I'd prefer everyone follow Chrome. We do so with FileEntry, in the sandbox, because it's intended to be a much more powerful API than File, and the security aspects of it are much simpler. When the user drags a File into the browser, it's much less clear that they intend to give the web app persistent access to that File, including all future changes until the page is closed. I don't think we'd rush to make that change to the spec. And if our implementation isn't snapshotting currently, that's a bug. In my reading of the spec, UAs explicitly instructed not to implement a snapshot. If so that's a bug in the spec. File and Blob objects are intended to contain constant data. For a file object returned frominput type=file I would expect the implementation to make all reads fail if the data changes on disk. I know we don't do this in Firefox right now, but I consider that a bug. The FileList object is what we're looking at. Yes, File and Blob should be constant data. When the underlying File data changes, the FileList object should point to the new file or otherwise not return the item in the list. Yes, Firefox has a bug: it is not creating a new File object when FileList is accessed for a modified file. It's not throwing an error on when the old File object is used. This seems like a relatively easy fix to FileList and the File object. -Charles
Re: File modification
On 1/12/2012 6:34 AM, Glenn Maynard wrote: Side-effects of event registration are outside of the DOM event model. UAs can do whatever transparent optimizations they want, of course, but APIs shouldn't *depend* on that for efficient implementations. Occasional polling definitely has significant overhead (directories may have tens of thousands of files, be on network shares, etc), and should be widely avoided. I also wonder whether change notifications work over eg. NFS. It would be bad if this feature only sometimes worked (especially if it breaks on major but less used configurations like NFS), since once deployed, apps will be designed around it. On NFS and directories where directory notification is not available: send an onchanged event to FileList when an underlying File object changes upon access of its entry in FileList. That is... as I'm looping through FileList grabbing files, it may invalidate a File object. FileList has now changed. I won't know until the next event loop. That's good enough.
Re: File modification
That's not good enough for many use cases. For example, a notepad app that saves to disk wants to update the display if another program modifies the file. You don't want that to be delayed until you scan the directory; you want the event pushed at you immediately when it happens. This is how I imagine most use cases looking. On Jan 12, 2012 10:16 AM, Charles Pritchard ch...@jumis.com wrote: On 1/12/2012 6:34 AM, Glenn Maynard wrote: Side-effects of event registration are outside of the DOM event model. UAs can do whatever transparent optimizations they want, of course, but APIs shouldn't *depend* on that for efficient implementations. Occasional polling definitely has significant overhead (directories may have tens of thousands of files, be on network shares, etc), and should be widely avoided. I also wonder whether change notifications work over eg. NFS. It would be bad if this feature only sometimes worked (especially if it breaks on major but less used configurations like NFS), since once deployed, apps will be designed around it. On NFS and directories where directory notification is not available: send an onchanged event to FileList when an underlying File object changes upon access of its entry in FileList. That is... as I'm looping through FileList grabbing files, it may invalidate a File object. FileList has now changed. I won't know until the next event loop. That's good enough.
Re: File modification
On Jan 12, 2012, at 6:58 AM, Kyle Huey m...@kylehuey.com wrote: On Thu, Jan 12, 2012 at 3:45 PM, Glenn Maynard gl...@zewt.org wrote: FYI, I don't think this is clear for File from the spec. It's even more important if File objects are stored in History or IndexedDB; that it should be a *shallow* copy, with enough information stored to invalidate it if the underlying file changes, doesn't seem to be specified. (As far as I know, nobody implements that yet; being able to eg. retain open files in History states would be extremely useful. Gecko nightlies are capable of storing File objects in IndexedDB, We are doing deep copies (what is retrieved from the database is always a copy of the file as it was when it was placed in the database). Oh I'm glad to see this one! Is it Blob and File that can be put into IDB? How do I create a new File (with a name field) from a Blob? Charles: see the thread on making Blobs constructable -- follow http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0439.html The File API specification should do a better job describing what happens to a File if the underlying resource changes. We use the word immutable, but I think we have to make this substantially clearer. -- A*
Re: File modification
On 1/12/12 12:53 PM, Arun Ranganathan wrote: On Jan 12, 2012, at 6:58 AM, Kyle Huey m...@kylehuey.com mailto:m...@kylehuey.com wrote: On Thu, Jan 12, 2012 at 3:45 PM, Glenn Maynard gl...@zewt.org mailto:gl...@zewt.org wrote: FYI, I don't think this is clear for File from the spec. It's even more important if File objects are stored in History or IndexedDB; that it should be a *shallow* copy, with enough information stored to invalidate it if the underlying file changes, doesn't seem to be specified. (As far as I know, nobody implements that yet; being able to eg. retain open files in History states would be extremely useful. Gecko nightlies are capable of storing File objects in IndexedDB, We are doing deep copies (what is retrieved from the database is always a copy of the file as it was when it was placed in the database). Oh I'm glad to see this one! Is it Blob and File that can be put into IDB? How do I create a new File (with a name field) from a Blob? Charles: see the thread on making Blobs constructable -- follow http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0439.html http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0918.html Seems like the consensus was to stay away from Blob to File methods. FileEntry and [a download] being the heirs apparent. The File API specification should do a better job describing what happens to a File if the underlying resource changes. We use the word immutable, but I think we have to make this substantially clearer. My take on a File object that's been modified is that the file no longer exists. User agents MUST process reads on files that no longer exist at the time of read as errors A file may change on disk since the original file selection, thus resulting in an invalid read. FileList is live; and UAs can go several ways with it. They can return new File objects, with updated information (yes, please); or they can otherwise cut out modified files or later, throw the security error as specified: Post-selection file modifications occur when a file changes on disk after it has been selected. In such cases, user agents MAY throw a SecurityError for synchronous read methods, or return a SecurityError DOMError for asynchronous reads.. It's a consideration, anyway. I don't think people expect that, if they select a file for uploading, then modify the file before hitting submit, that they'll no longer upload a file. It would, I suppose, disappear from the Chosen file option. There is a significant difference between selecting files and mounting a directory for persistent access. In one of them, the files are listed and new files are not added. So I may select a single file, and it'll show up in input type=file, or I'll see a count of the files I selected. With mounting a directory, I'm given continued access to poll for new files. I think that's enough of a distinction to keep the current behavior of allowing persistent access to selected files via FileList. If it's not enough of a distinction, I'd like more semantics added to requestFileSystem to re-establish the persistent selection of files. -Charles
Re: File modification
I don't follow. Either the user always has to poll the Entry to trigger the event, or you never have to. The former defeats the purpose of having an event (optimized by OS change notifications, low-overhead and instantaneous); the latter may not be possible (NFS). You can't have a web API where you only sometimes have to do something. (I think CIFS does support change notifications, based on UI observations. I wonder if this will show up in NFS. I know that file changes show up immediately in Windows file explorer windows over CIFS, but not NFS.) On Jan 12, 2012 10:51 AM, Charles Pritchard ch...@visc.us wrote: You're at the mercy of many types of latency with web apps. For the high-importance notepad case, you're talking about one file. I can poll every second from my web app and back off when the screen is idle, with current code in Chrome. Hooking into OS level file notification would give better results, and help me back off the polling. And if it's on NFS, and there's no update signal, looping through FileList would still get me my event. NFS and thousands of files are an extreme case. But they can be managed and an update event would improve that management. -Charles On Jan 12, 2012, at 10:20 AM, Glenn Maynard gl...@zewt.org wrote: That's not good enough for many use cases. For example, a notepad app that saves to disk wants to update the display if another program modifies the file. You don't want that to be delayed until you scan the directory; you want the event pushed at you immediately when it happens. This is how I imagine most use cases looking. On Jan 12, 2012 10:16 AM, Charles Pritchard ch...@jumis.com wrote: On 1/12/2012 6:34 AM, Glenn Maynard wrote: Side-effects of event registration are outside of the DOM event model. UAs can do whatever transparent optimizations they want, of course, but APIs shouldn't *depend* on that for efficient implementations. Occasional polling definitely has significant overhead (directories may have tens of thousands of files, be on network shares, etc), and should be widely avoided. I also wonder whether change notifications work over eg. NFS. It would be bad if this feature only sometimes worked (especially if it breaks on major but less used configurations like NFS), since once deployed, apps will be designed around it. On NFS and directories where directory notification is not available: send an onchanged event to FileList when an underlying File object changes upon access of its entry in FileList. That is... as I'm looping through FileList grabbing files, it may invalidate a File object. FileList has now changed. I won't know until the next event loop. That's good enough.
Re: File modification
On Wed, Jan 11, 2012 at 12:22 PM, Charles Pritchard ch...@jumis.com wrote: On 1/11/2012 9:00 AM, Glenn Maynard wrote: This isn't properly specced anywhere and may be impossible to implement perfectly, but previous discussions indicated that Chrome, at least, wanted File objects loaded from input elements to only represent access for the file as it is when the user opened it. That is, the File is immutable (like a Blob), and if the underlying OS file changes (thus making the original data no longer available), attempting to read the File would fail. (This was in the context of storing File in structured clone persistent storage, like IndexedDB.) Mozilla seems to only take a snapshot when the user opens the file. Chrome goes in the other direction, and does so intentionally with FileEntry. I'd prefer everyone follow Chrome. We do so with FileEntry, in the sandbox, because it's intended to be a much more powerful API than File, and the security aspects of it are much simpler. When the user drags a File into the browser, it's much less clear that they intend to give the web app persistent access to that File, including all future changes until the page is closed. I don't think we'd rush to make that change to the spec. And if our implementation isn't snapshotting currently, that's a bug. The spec on this could be nudged slightly to support Chrome's existing behavior. From dragdrop: http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html The files attribute must return a live FileList sequence http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#live If a DOM object is said to be live, then the attributes and methods on that object must operate on the actual underlying data, not a snapshot of the data. Dragdrop continues: for a given FileList object and a given underlying file, the same File object must be used each time. Given that the underlying file can change, and the FileList sequence is live, it seems reasonable that subsequent reads of FileList would access a different File object when the underlying file has changed. FileList.onchanged would be appropriate. File.onupdated would not be appropriate. Entry.onupdated would be appropriate. I have one major technical concern: monitoring files for changes isn't free. With only a DOM event, all instantiated Files (or Entries) would have to monitor changes; you don't want to depend on do something if an event handler is registered, since that violates the principle of event handler registration having no other side-effects. Monitoring should be enabled explicitly. I also wonder whether this could be implemented everywhere, eg. on mobile systems. At this point, iOS still doesn't allow input type=file nor dataTransfer of file. So, we're looking far ahead. A system may send a FileList.onchanged() event when it notices that the FileList has been updated. It can be done on access of a live FileList when a mutation is detected. It could be done by occasional polling, or it could be done via notify-style OS hooks. In the first case, there is no significant overhead. webkitdirectory returns a FileList object that can be monitored via directory notification hooks; again, if the OS supports it. Event handlers have some side effects, but not in the scripting environment. onclick, for example, may mean that an element responds to touch events in the mobile environment. -Charles
Re: File modification
On 1/11/2012 12:27 PM, Eric U wrote: On Wed, Jan 11, 2012 at 12:22 PM, Charles Pritchardch...@jumis.com wrote: On 1/11/2012 9:00 AM, Glenn Maynard wrote: This isn't properly specced anywhere and may be impossible to implement perfectly, but previous discussions indicated that Chrome, at least, wanted File objects loaded from input elements to only represent access for the file as it is when the user opened it. That is, the File is immutable (like a Blob), and if the underlying OS file changes (thus making the original data no longer available), attempting to read the File would fail. (This was in the context of storing File in structured clone persistent storage, like IndexedDB.) Mozilla seems to only take a snapshot when the user opens the file. Chrome goes in the other direction, and does so intentionally with FileEntry. I'd prefer everyone follow Chrome. We do so with FileEntry, in the sandbox, because it's intended to be a much more powerful API than File, and the security aspects of it are much simpler. When the user drags a File into the browser, it's much less clear that they intend to give the web app persistent access to that File, including all future changes until the page is closed. I don't think we'd rush to make that change to the spec. And if our implementation isn't snapshotting currently, that's a bug. In my reading of the spec, UAs explicitly instructed not to implement a snapshot. Everything in the specs talks about underlying data. They are to keep the FileList live, and failing that, or should the underlying file be removed, they should throw an error when the File object is used with FileReader or the like. I've written code for Chrome that detects file changes, so it'd be a bit of a bummer to see this feature removed without suitable replacement. FileEntry does not currently work with DD as well as File. I don't think it's caught up yet. I can't drag a FileEntry into input type=file on another site. From dragdrop: http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html The files attribute must return a live FileList sequence http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#live If a DOM object is said to be live, then the attributes and methods on that object must operate on the actual underlying data, not a snapshot of the data. Dragdrop continues: for a given FileList object and a given underlying file, the same File object must be used each time. Underlying is an important distinction here. For persistent directory access, we talked about using requestFileSystem(MOUNT). -Charles
Re: File modification
(Pardon the top-quoting and poor editing; working off a phone today.) This isn't properly specced anywhere and may be impossible to implement perfectly, but previous discussions indicated that Chrome, at least, wanted File objects loaded from input elements to only represent access for the file as it is when the user opened it. That is, the File is immutable (like a Blob), and if the underlying OS file changes (thus making the original data no longer available), attempting to read the File would fail. (This was in the context of storing File in structured clone persistent storage, like IndexedDB.) (I don't know if this was thought to apply to FSAPI-acquired Files as well, eg. requiring the user to request a new File from the Entry after modifying it. That would be annoying, but it would preserve the invariant that Blobs are immutable, which shouldn't be sacrificed lightly.) That would make onchanged not meaningful for File. However, it would be useful on Entry instead. I have one major technical concern: monitoring files for changes isn't free. With only a DOM event, all instantiated Files (or Entries) would have to monitor changes; you don't want to depend on do something if an event handler is registered, since that violates the principle of event handler registration having no other side-effects. Monitoring should be enabled explicitly. I also wonder whether this could be implemented everywhere, eg. on mobile systems. On Jan 10, 2012 1:58 PM, Charles Pritchard ch...@jumis.com wrote: On Jan 10, 2012, at 1:53 PM, Eric U er...@google.com wrote: On Tue, Jan 10, 2012 at 1:29 PM, Charles Pritchard ch...@visc.us wrote: Modern operating systems have efficient mechanisms to send a signal when a watched file or directory is modified. File and FileEntry have a last modified date-- currently we must poll entries to see if the modification date changes. That works completely fine in practice, but it doesn't give us a chance to exploit the efficiency of some operating systems in notifying applications about file updates. So as a strawman: a File.onupdated event handler may be useful. It seems like it would be most useful if the File or FileEntry points to a file outside the sandbox defined by the FileSystem spec. Does any browser currently supply such a thing? Chrome currently implements this [with FileEntry] only for ChromeOS components that are implemented as extensions. Does any browser let you have a File outside the sandbox *and* update its modification time? If you're dealing only with FileEntries inside the sandbox, there are already more efficient ways to tell yourself that you've changed something. Far as I can tell, File is live, and it's supposed to be live from input type=file. For FileEntry-- I'd imagine we'll see cross-origin communication with the objects at some point. In those cases, onupdated would be simpler than an additional postMessage layer for update notifications.
Re: File modification
On 1/11/2012 9:00 AM, Glenn Maynard wrote: This isn't properly specced anywhere and may be impossible to implement perfectly, but previous discussions indicated that Chrome, at least, wanted File objects loaded from input elements to only represent access for the file as it is when the user opened it. That is, the File is immutable (like a Blob), and if the underlying OS file changes (thus making the original data no longer available), attempting to read the File would fail. (This was in the context of storing File in structured clone persistent storage, like IndexedDB.) Mozilla seems to only take a snapshot when the user opens the file. Chrome goes in the other direction, and does so intentionally with FileEntry. I'd prefer everyone follow Chrome. The spec on this could be nudged slightly to support Chrome's existing behavior. From dragdrop: http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html The files attribute must return a live FileList sequence http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#live If a DOM object is said to be live, then the attributes and methods on that object must operate on the actual underlying data, not a snapshot of the data. Dragdrop continues: for a given FileList object and a given underlying file, the same File object must be used each time. Given that the underlying file can change, and the FileList sequence is live, it seems reasonable that subsequent reads of FileList would access a different File object when the underlying file has changed. FileList.onchanged would be appropriate. File.onupdated would not be appropriate. Entry.onupdated would be appropriate. I have one major technical concern: monitoring files for changes isn't free. With only a DOM event, all instantiated Files (or Entries) would have to monitor changes; you don't want to depend on do something if an event handler is registered, since that violates the principle of event handler registration having no other side-effects. Monitoring should be enabled explicitly. I also wonder whether this could be implemented everywhere, eg. on mobile systems. At this point, iOS still doesn't allow input type=file nor dataTransfer of file. So, we're looking far ahead. A system may send a FileList.onchanged() event when it notices that the FileList has been updated. It can be done on access of a live FileList when a mutation is detected. It could be done by occasional polling, or it could be done via notify-style OS hooks. In the first case, there is no significant overhead. webkitdirectory returns a FileList object that can be monitored via directory notification hooks; again, if the OS supports it. Event handlers have some side effects, but not in the scripting environment. onclick, for example, may mean that an element responds to touch events in the mobile environment. -Charles
Re: File modification
On Tue, Jan 10, 2012 at 10:57 PM, Charles Pritchard ch...@jumis.com wrote: Far as I can tell, File is live, and it's supposed to be live from input type=file. FWIW, I (and I believe others at Mozilla) consider the fact that File objects are live in Gecko a bug. Fixing this is kind of complicated in our implementation though, and I've had other things to work on, so it's still there. - Kyle
Re: File modification
On 1/11/2012 12:37 PM, Kyle Huey wrote: On Tue, Jan 10, 2012 at 10:57 PM, Charles Pritchard ch...@jumis.com mailto:ch...@jumis.com wrote: Far as I can tell, File is live, and it's supposed to be live from input type=file. FWIW, I (and I believe others at Mozilla) consider the fact that File objects are live in Gecko a bug. Fixing this is kind of complicated in our implementation though, and I've had other things to work on, so it's still there. Sorry I misspoke on this one. FileList is supposed to be live. File objects are immutable. The bug (in my opinion) is that FileList returns the same File object when the underlying length/date has changed. It ought to return a new File object (in my opinion), and references to the old File object should return an error when used with items like FileReader. They're dirty blobs, out of control masses of green goo. -Charles
Re: File modification
On Tue, Jan 10, 2012 at 1:29 PM, Charles Pritchard ch...@visc.us wrote: Modern operating systems have efficient mechanisms to send a signal when a watched file or directory is modified. File and FileEntry have a last modified date-- currently we must poll entries to see if the modification date changes. That works completely fine in practice, but it doesn't give us a chance to exploit the efficiency of some operating systems in notifying applications about file updates. So as a strawman: a File.onupdated event handler may be useful. It seems like it would be most useful if the File or FileEntry points to a file outside the sandbox defined by the FileSystem spec. Does any browser currently supply such a thing? Chrome currently implements this [with FileEntry] only for ChromeOS components that are implemented as extensions. Does any browser let you have a File outside the sandbox *and* update its modification time? If you're dealing only with FileEntries inside the sandbox, there are already more efficient ways to tell yourself that you've changed something.
Re: File modification
On Jan 10, 2012, at 1:53 PM, Eric U er...@google.com wrote: On Tue, Jan 10, 2012 at 1:29 PM, Charles Pritchard ch...@visc.us wrote: Modern operating systems have efficient mechanisms to send a signal when a watched file or directory is modified. File and FileEntry have a last modified date-- currently we must poll entries to see if the modification date changes. That works completely fine in practice, but it doesn't give us a chance to exploit the efficiency of some operating systems in notifying applications about file updates. So as a strawman: a File.onupdated event handler may be useful. It seems like it would be most useful if the File or FileEntry points to a file outside the sandbox defined by the FileSystem spec. Does any browser currently supply such a thing? Chrome currently implements this [with FileEntry] only for ChromeOS components that are implemented as extensions. Does any browser let you have a File outside the sandbox *and* update its modification time? If you're dealing only with FileEntries inside the sandbox, there are already more efficient ways to tell yourself that you've changed something. Far as I can tell, File is live, and it's supposed to be live from input type=file. For FileEntry-- I'd imagine we'll see cross-origin communication with the objects at some point. In those cases, onupdated would be simpler than an additional postMessage layer for update notifications.
