On 10/21/14 4:36 PM, Ali Alabbas wrote:
Hello,
I'm with the IE Platform team at Microsoft. We have a few comments on
the latest editor's draft of the newly proposed FileSystem API [1].
I believe [1] is Arun's <http://w3c.github.io/filesystem-api/Overview.html>.
1.1 Use cases (3. Audio/Photo editor with offline access or local
cache for speed)
* Edited files should be accessible by other client-side applications
- Having the sandboxed file system share its contents between all apps
would allow apps to tamper with the files of another app. This could
result in corrupted files and perhaps an invalid state for some apps
that expect certain contents to exist in a file. This makes us wonder:
should we warn users about files that are being opened and written to?
If an app is just doing a read, can it open a file or directory
without the user's permission, or could this pose a possible issue as
well? Also, is the Quota Management API going to be a dependency? It's
unclear what we would do with regards to requesting permission to
access files. Will this spec be responsible for defining what
questions/permission inquiries are presented and when they are
presented to the user? For example, what happens when one file is
locked for use by a different application? Is the user notified and
given the option to open a read-only copy of that file?
3. The Directory Interface
* Change events
- I would like to revisit the discussion on apps getting notifications
of changes to files/directories. There are many scenarios where an
application would want to react to renames/moves of a file/directory.
There would also be value in being notified of a change to a
directory's structure. If an app has a file browser that allows a user
to select files and/or directories and another app makes changes to
the sandboxed filesystem, then it would be expected that the first app
should be notified and would be able to refresh its directory tree.
Otherwise it would require the user to somehow force a refresh which
would not be a good user experience since the user would expect the
file browser to update on its own.
* removeDeep() & move()
- Do these support links or junctions? If not, what is the expected
behavior?
* enumerate()
- It would be useful to have pre-filtering support for the following:
file/directory, ranges, wildcard search. Currently we would be forced
to enumerate the entire set and manually filter out the items we want
from the result set.
- Callers often know exactly whether or not they want to enumerate
files or folders. For example, an image upload service may only be
interested in the files present in a directory rather than all of its
directories. Perhaps it would be useful to have enumerateFiles() and
enumerateDirectories() for this purpose? Or we could have another
argument for enumerate() that is an enum ("directory", "file").
- Supporting optimized pagination of large directories. We could have
arguments for a starting index and length we would be able to specify
a range of items to retrieve within the result set.
- Supporting the wildcard character to pre-filter a list of
files/directories (e.g. *.jpg).
4. The FileHandle Interface
* FileHandles
- Is this basically going to be the first to get the handle gets to
use it and all subsequent calls need to wait for the file handle to
become available again? Are there more details about the locking model
used here?
* Auto-closing of FileHandles
- This may cause confusion as it does not match the common developer
mental model of a file handle which is “opened” and then available for
use until it's “closed”. Perhaps it would be advantageous to have an
explicit close function as part of the FileHandle interface? With the
current behavior there can be overhead with the unintended closure of
the FileHandle that would require a developer to continuously
open/close a FileHandle. The currently defined behavior assumes that a
developer is done with all their file manipulations when they have
completed a promise chain. However, a developer may want to keep the
FileHandle open to be used elsewhere at some other point in time that
is not related to the current promise chain. An example of the
usefulness of having an explicit close function is if you were to
implement a word processor and wanted to lock down the file that it
currently has open for the period of its editing. This way you are
free to continue operating on that file for the duration that it is
open, protecting the file from other processes, and not having to
undergo the costly setup and teardown of a file handle.
* AbortableProgressPromise
- It is not clear how a developer would define the abort callback of
an AbortableProgressPromise. It seems that the user agent would be
responsible for setting the abort callback since it instantiates and
returns the AbortableProgressPromise.
5. The FileHandleWritable Interface
* write() & flush()
- It might be useful to have support for “transacted” streams where
the caller can write to a copy of the file and then have it atomically
replaced: swap the old file with the new one and then delete the old
file. This reduces the opportunity for an app crash to lead to a
corrupted file on disk; it would be corrupted without transacted
streams if the app crashes during save. The transacted streams could
be handled during the (automated) flush where the user agent would
write to a temp file and atomically replace the intended file.
* flush()
- This is costly functionality to expose and is likely to be overused
by callers. It would be beneficial to automatically flush changes to
disk by allowing the default file write behavior by the OS. For
example, on Windows, we would leave it up to the filesystem cache to
determine the best time to flush to disk. This is non-deterministic
from the app's point of view, but the only time it is a potential
problem is when there's a hard power-off. Most apps should not be
concerned with this; only apps that have very high data reliability
requirements would need the granular control of flushing to disk. In
those cases a developer should use IndexedDB. So we should consider
obscuring this functionality since it's not a common requirement and
has a performance impact if it's widely used.
6. FileSystem Configuration Parameters
* Dictionary DestinationDict
- The DestinationDict seems to exist to facilitate the renaming of a
directory in conjunction with a move. However, the same operation is
done differently for files which makes the functionality non-uniform.
Perhaps we can add a rename() function to make it more intuitive?
Thank you,
Ali
