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" <chuck@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 drag&drop:
> http://www.whatwg.org/specs/**web-apps/current-work/**multipage/dnd.html<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<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
>
>
>