- From: Brandon Benvie <bbenvie@mozilla.com>
- Date: Fri, 09 Aug 2013 21:00:38 -0700
- To: public-script-coord@w3.org
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