Re: Request for feedback: Filesystem API

Domenic Denicola wrote:
>   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,

Filesystems are old, in OSes and the OS research literature.

>   while at the same time exercising caution in exactly how file system APIs are designed.

Caution and nuance are fine things. It's hard to make progress with this 
kind of appeal to universals. The particular design is what we should 
focus on, based in part (not in whole) on the long history of filesystem 
and OS design experience.

> 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.

That's a small-N sample with plenty of volunteer effect, aka selection bias.

Can we get back to the particulars? A bit more of that and less of the 
warring non-exclusive universals, please.

Here's a particular question your comment prompts: Chrome's Filesystem 
API, IIRC, was meant to map to files and directories that users could 
rendezvous with via other tools, depending on the OS in question. Is 
this a non-goal of the current webapps filesystem work?

/be