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

Received on Sunday, 2 June 2013 21:42:12 UTC