Ali, First, thanks for your timely comments :) I’m in the process of editing the FileSystem API.
Responses inline: On Oct 21, 2014, at 4:36 PM, Ali Alabbas <a...@microsoft.com> wrote: > > 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. <snip /> Admitedly, these use cases have been borrowed from the “File API: Directories and System” specification (which is now a W3C Note), at least for the purpose of providing equivalent functionality. In practice, everything you’ve pointed out makes it a hard problem to solve. The per-origin sandbox model also raises file lock issues on multiple access, but they are probably easier to solve, and not as prevalent. Also, we’re going to forego the “temporary” and “persistent” distinctions that are in the draft I think. And while there’s a technical dependency on Quota Manager, I don’t think there’s a spec. dependency in terms of API. Of course, certain Directory operations may reject a promise with a quota error. > > > 3. The Directory Interface > > * Change events > - I would like to revisit the discussion on apps getting notifications > of changes to files/directories. This is a good point; right now there’s no way to do this. I’m open to suggestions. An early scratch pad version of my spec. changes proposed Directory as an EventTarget also, but… this won’t work for a variety of reasons. > > * removeDeep() & move() > - Do these support links or junctions? If not, what is the expected > behavior? No; but the entire API doesn’t support these right now. > > * 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. I completely agree this would be useful, but there’s a problem to solve even before we get there! Right now, we say that we’ll fullfill the enumerate promise with something called “EventStream” which was initially a Tab Atkins proposal, and which would be really useful to get right. It’s underspecified right now, but I’m a fan of it ;-) We’ll have to think about how to return wildcard searches, etc., and how to annotate results in the result set. > > 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? Yes; essentially the “first invocation” uses then releases it. A version of this problem was encountered when specifying FileReader (http://dev.w3.org/2006/webapi/FileAPI/#dfn-filereader) which used the internal state (but also accessible to the developer) “LOADING” to prevent multiple concurrent reads. > > * 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? There are pros and cons either way. I’d be interested in solving this for the lion’s share of use cases. I’m not strongly opinionated on the matter of an explicit close function (we have one on Blob, for example), but it seems even this has drawbacks. > * 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. We’re going to not use an AbortableProgressPromise, but we will probably have a new beast called CancelablePromise. > > > 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. Agreed. > > * flush() > - This is costly functionality to expose and is likely to be overused by > callers. Agreed — let’s flush flush(). > 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? > I’ll commit to sample code and more “spec text” to make this clearer in my next push. But I like the idea of an explicit rename() actually. — A*
