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 drag&drop:
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."

Drag&drop 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

Received on Wednesday, 11 January 2012 20:49:47 UTC