Re: Request for feedback: Filesystem API

I reserve the right to quibble about details of your API, but I think the issues below are more significant than the actual API design


On Aug 9, 2013, at 4:22 PM, Jonas Sicking wrote:

> On Fri, Aug 9, 2013 at 4:02 PM, Rick Waldron <waldron.rick@gmail.com> wrote:
>> below...
>> 
> ...
>> I don't know how set in stone the naming is, but you might also consider
>> reviewing some prior art (http://nodejs.org/api/fs.html) for method names
>> call signatures.
> 
> Nothing is set in stone at this point.

1) It not clear to me why a completely new filesystem design and API is needed for the web platform.  We have decades of experience with file systems and their APIs and have reached the point where there is only a handful of widely used designs in the world. I don't see why one of these designs (eg, Posix) couldn't be adopted by the web platform.  No matter how simply you start it seems inevitable that the web platform FS will evolve to have all the features of a modern files system, so why not just start with an existing one.

Sure there may need to be some minor tweaks to avoid blocking (and that's also not a requirement that isn't unique to the web platform or JS) and to accommodate the browser's security model, but it should still be possible to very closely track proven technology.

BTW, the nodejs api looks like a pretty good start at a comprehensive API although there are no doubt both major and minor things that could be debated about it.

2) I expect JS programmer to want most file code to be portable among host platforms.  There is no particular reason that the same JS code that does basic file operations should have to change when moved from a browser, to node, to a bare-bones OS command-line enviornment. It works for C, we can do it for JS.

But to get there the API needs to be designed from that perspective rather than for one specific host environment.  Perhaps that suggests that this design work should be done as a TC-39 supplemental spec. 

Allen