Re: Request for feedback: Filesystem API

On 8/9/2013 7:25 PM, Domenic Denicola wrote:
> Jonas, I think this looks great for the most part, and am excited about the broad strokes of the API: promise-based, fairly simple interface, no POSIX-like cryptic names (e.g. "unlink"), and I especially appreciate you guys taking the time to think through the multi-process stuff so that those of us who aren't familiar with such things don't have to do so.
>
> However, I think one major issue with the interface is that it is about as far as a proposal possibly could be from embracing the extensible web principles that we've recently been pushing [1]. A filesystem API seems like the *perfect* candidate for applying the "add new low-level capabilities, allow web developers to iterate on higher-level ones, then standardize later" approach.
>
> For example:
>
> - At a glance, move, copy, removeDeep, and enumerateDeep seem like derivative APIs.

Coming from a completely neutral understanding (no one has talked to me 
about this), these are, at the naive level, derivative APIs. In reality, 
they are also mostly extremely optimizable operations.

* move: optimized as a record rename, no need for data movement
* copy: optimized as two pointers to the same data with a notation on 
dependencies
* removeDeep: a notation on the container that all contained data is removed

Naively implementing these things in terms of read/write and delete is 
of course possible, but also unboundedly less efficient. I don't think 
it's a good idea to try and decompose them to that extreme.

To decompose these into their primitive operations would require 
exposing things at a level lower than almost anyone is willing to touch. 
I agree in concept with decomposing to primitives, but in this case in 
would mean decomposing to something almost no-one is capable of building 
on top of.

Received on Saturday, 10 August 2013 04:01:19 UTC