RE: Request for feedback: Filesystem API

From: Jonas Sicking [mailto:jonas@sicking.cc]

> You can do file-copying using createFile and pass in an existing File object. So I think you are simply arguing for copy() to be removed.

I didn't see that overload in the initial proposal. I guess it is part of the `DOMString or Blob or ArrayBuffer or ArrayBufferView` union? In which case, yeah, I guess I am. (I wish we didn't have so much overloading, sigh.)

> So it sounds like we are in agreement that the lowest-level primitive isn't always the right one to expose. The question is how low to go and generally that is a judgement call.

I don't think this is giving enough credit to the extensible web point of view. The issue isn't "always expose the lowest level primitive possible," because then we'd just be exposing asm.js with some C bindings and be done with it. The issue is to give developers new capabilities they've never had before---like file system access---but don't try to do higher-level API design on the W3C side, at least at first. Let developers have input into the process, not via mailing lists, but via actually building stuff in the real world. At the very least, if you are going to do higher-level APIs, prototype it (and preferably spec it) in JavaScript, so that it gains the many benefits outlined on extensiblewebmanifesto.org. Trying to characterize my position as "just expose block-level storage" on the one hand, or an equivocating "yeah, don't expose the lower-level stuff always, it's a judgment call" on the other hand, doesn't do justice to the nuance of seeing file system access as a new developer capability, while at the same time exercising caution in exactly how file system APIs are designed.

On the other hand, when I actually showed this to developers, the reaction was uniformly "why can't we just build this on top of IndexedDB" :(. They kind of acquiesced when they re-read your sentence explaining that this may eventually extend to real file systems. Unfortunately none of them were willing to wade into what they called the "mailing list bureaucracy," instead preferring a "representative democracy" approach where they send their concerns via me instead. So, just as a side note, that's the voice of the developers I've been talking to. I can't imagine it's that helpful in light of how you've already outlined this proposal's departures from IndexedDB, but that's the sentiment on the ground, at least.

Received on Wednesday, 14 August 2013 01:57:45 UTC