Re: FileSystem API Comments

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
>

Received on Tuesday, 21 October 2014 21:02:30 UTC