RE: Request for feedback: Filesystem API

> I think this cuts to the core of your argument. My vision was to have
> a low-level API. Like you say, conflict resolution can be handled so
> many ways so I think it's best handled by libraries or by
> application-level logic.

It's totally fine, but then I'm with Domenic: I would object to any non-atomic function. Any non-atomic function either requires proper hooks to handle its non-atomicity or needs to be removed from the API surface, to avoid the risk of creating a state where a bad API get used because it's built-in, and does more bad than it does good.

There's a very well known problem [1] around roads and traffic where adding a road between two cities to make things more convenient would actually decrease the traffic bandwidth (because people tend to act in a way that do optimize their own commute and not the overall commute time).

Adding new APIs is not free of cost, and it better not be that extraneous road that made the whole thing less stable (because, you know, we actually can't remove it once it shipped).


  [1] http://en.wikipedia.org/wiki/Braess%27s_paradox



> An API like what you are proposing is certainly very interesting, but
> it's something that I think should be written as a library on top of
> the low-level API provided by the platform.
>
> But like you point out, in order to let applications/libraries handle
> this, we need the correct primitives in the platform API.
>
> My hope was that you could use enumerate() recursively to enumerate
> the source tree. For each found file/directory use
> createFile()/createDirectory() to create entries in the target tree.
> If this fails with a "already exists" error then you can handle the
> error in whatever way you want and then keep enumerating once
> appropriate.
>
> We'll definitely try to write some code to test this out once we have
> a better understanding of what the "EventStream" (aka "async iterator"
> aka "cursor") looks like.
>
> It would be cool though to find a way to support this without
> requiring the use of recursive enumerate() calls, since async
> recursive code is not that pretty. enumerateDeep() almost takes care
> of this, except that enumerateDeep() only returns Files which means
> that it misses empty directories.
>
> I haven't found a way to change enumerateDeep() such that it also
> exposes empty directories without creating an API that is too messy.
> Suggestions encouraged!

EnumerateDeep suffer from the same issues. What happens if enumerating a sub-folder fails because of security right?

The issue with any non-atomic operation is the same every time: it either needs an API that allows to recover from internal errors, or it should be removed to encourage developers to care about the issues themselves.



>> What about someone trying to delete a file that is currently in use?
>
> This is a good question. One that applies for for multi-file
> operations as well as the simple remove()/removeDeep() primitives.
>
> Whatever we do for the remove()/removeDeep() primitive, I propose that
> we do for non-atomic-move()s.

Remove and removeDeep are two different beasts. I may totally want to "stop at first issue" or "ignore all issues" when facing an error inside removeDeep, or ask the user what to do (including giving him the chance to resolve the lock and retry).



The Windows blog posts are certainly about UI, but they're also about all the stuff that you want to allow with your API. Showing current progress, Pausing, Aborting, Dealing with conflicts asynchronously using UI, Creating automatic rules for conflicts, ...

If your API provides high-level API, it has to work well with those needs, or it means it's the wrong primitive. I'm totally with Domenic when it says that if we don't feel we have or can implement the right high-level API now, we have to leave this entirely to JavaScript libraries.

Received on Monday, 19 August 2013 21:22:20 UTC