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].
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
