W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2013

Re: Request for feedback: Filesystem API

From: Brandon Benvie <bbenvie@mozilla.com>
Date: Fri, 09 Aug 2013 21:00:38 -0700
Message-ID: <5205BAE6.5060909@mozilla.com>
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 
* 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:17 UTC