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
