On 10/18/2013 11:11 AM, Jeremie Patonnier wrote:
2013/10/18 Ehsan Akhgari <ehsan.akhg...@gmail.com
<mailto:ehsan.akhg...@gmail.com>>
Have you seen this proposal?
<http://lists.w3.org/Archives/Public/public-script-coord/2013JulSep/0379.html>
It's not clear to me if your proposal here is trying to solve
problems that the above proposal doesn't already solve...
Yes, I saw that proposal but no, I do not suggest to solve the same
problem.
I found that proposal for an abstract file system very good when the
application have to work in its own world.
Unfortunately there is a few cases where it is very convenient to
allow to actually truly write on the os file system.
Here a few concrete example:
* When the user want to export his file to an external storage (Hard
drive, USB storage, SD Card, etc.) In that case it where web dev
use the data URI workaround to "download" the file.
* When the user want to use a resource available in its file system
and want to update that resource with any change he made to have
some other application using it as well (mostly native apps on
desktop). For example, editing an image and put it back on the
file system to have another native application accessing it (let's
say for example Adobe Lightroom). So being able to open a file and
perform (silent) saving on the original file allows to build
smoother workflow when using a native app and a web app at the
same time.
Chrome has a secured extension for maintaining access to the local file
system:
http://developer.chrome.com/apps/fileSystem.html
They only allow this for "packaged applications". This, with the
FileSystem API allows for -most- of what you'd like. While it can be a
little clumsy to work with, so can IDB; it just takes some wrapping
code. As discussed, an easier promises based API is being developed by
Mozilla, and while it's questionable as to whether Google or other
vendors will follow, wrapping existing callback APIs into promises is
not a big deal in the JS-side.
Unfortunately, nobody has stepped forward with concrete code for file
watchers. The File API itself is a little "broken", as File objects were
supposed to be immutable, but we have undefined behavior when a File is
changed on the local file system.
http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0846.html
http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0431.html
-Charles
