RE: Request for feedback: Filesystem API

> On Mon, Aug 19, 2013 at 2:21 PM, François REMY
> <francois.remy.dev@outlook.com> wrote:
>>> 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.
>
> The only non-atomics that we have are:
>
> * move() between different filesystems. 

and also move() when there's already a folder using the same name at the specified location, and therefore conflicts. I guess keeping move() for files only is rather safe, though. It can simply fail on conflicts and provide meaningful errors. We can also specify that if such folder exists, the move fails and then allow the function for directories, too.




> We have the choice here of
> making move() between different filesystems fail, or act in a
> non-atomic fashion. Both Brendan and I have asked for clarification of
> what people prefer in this thread but with no answer so far. I prefer
> to keep it working and act non-atomic, and I'm tempted to keep it that
> way until we have some polyfill experience.

Again, I'm not a fan of the fact that if the operation fails during the process (ie: the copy worked but not the delete) then you're stuck with an incomplete error handling. HOWEVER, this specific case could be solved by providing more details in the exception being thrown (or the just created copy could be deleted and therefore the original state restaured) and I would be fine with that.




> * enumerate() We need a way to enumerate, and I don't see a way to
> make enumerate() atomic. So this one I think we're stuck with.

It's not completely non atomic though. We can make it return a kind of Iterator and define how it reacts to changes to the folder being enumerated), including throwing on a call to next(). That's totally acceptable.




> * deleting directories. I'll have to think more about this one.

Definitely not a fan of that if we do not provide error handling hooks, indeed.




> * enumerateDeep() I think this one is needed to avoid forcing people
> to deal with async recursion in the common cases. And it is no less
> atomic, i.e. no more problematic, than enumerate().

we can maybe tweak the enumerator to provide basic exception handling in this specific case. using my proposed pattern that would be something alike those lines:

   // ignore any error
   var it = directory.initIteration({ recursive: true });
   for(let nodes of it) {
      ...
   }   

   // abort on error
   var it = directory.initIteration({ recursive: true });
   it.onIterationError = function(e) {
      e.target.abort();
   }
   for(let nodes of it) {
      ...
   }

but we can allow something closer to what you define, most probably.

Received on Monday, 19 August 2013 22:34:26 UTC