Re: [File System APIs] If one is good, then two must be better?

On Feb 5, 2014, at 7:03 AM, Charles McCathie Nevile wrote:
> Similarly the issue here is not whether we can make a specification for
> one or the other approach that *could* be a standard, since it seems we
> can, but whether one or the other is a clear candidate to be a real
> standard - i.e. what people *will* actually do...
> 
> I think one of the mistakes with IndexedDB (and appcache for that matter)
> was that the participants in the discussion were too heavily biased toward
> browser implementors, without enough input or involvement from "working
> developers". Which meant that we standardised something that didn't meet
> people's expectations as well as we and they hoped.


Of course I agree that the path to standardization should involve input from developers, and should be based on "what people will actually do."  There's been some support for a Promises-based FileSystem API in lieu of a callback-based one, both on this listserv and on public-script-coord, which is where the proposal started: 
http://lists.w3.org/Archives/Public/public-script-coord/2013JulSep/0379.html

To borrow an expression from that thread, we're not "blank-slateists" here: there are 3 separate APIs for JavaScript file system APIs, including the one in node.js (implemented as a posix-style API, familiar from other programming environments), from Google (implemented in Chrome as a callbacks-based asynchronous API), and from Mozilla (implementing the proposal we're discussing here [1], but sandboxed as of now). This is a call for feedback, from web developers and implementers.  I only made the point that when considering *implementations* we should consider similar beasts.    

The thread about having a FileSystem API is a long one, and goes back a long time.  The motivation is to provide something asynchronous (but not callbacks stapled to posix shells), in keeping with the flavor of APIs currently deployed for the web (Promises, not events or callbacks), that is easy to use and with a low probability of doing bad things.  Feedback from web developers about that endeavor is invaluable.


> I hope that when we make a choice it's one that not only matches the
> reality of what gets implemented, but helps us provide what the market
> really wants. I presume everyone here hopes for that. I think a key part
> of how to get there is to listen carefully to the feedback we get, and
> look around at what people are doing, rather than just relying on
> formulaic rules of thumb or bureaucratic tallying of test results.


I agree with the spirit behind this comment, and am optimistic that you don't actually think that the call for opinions on a proposal, or the call for implementor support, is a sign of a "formulaic rule of thumb" or a "bureaucratic tallying of test results."

-- A*
[1] Interfaces only: http://w3c.github.io/filesystem-api/Overview.html