Re: Request for feedback: Filesystem API

On Fri, Aug 9, 2013 at 6:25 PM, Allen Wirfs-Brock <allen@wirfs-brock.com> wrote:
> 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

Thank you for focusing on the big-picture issues first!

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

For what it's worth, we did model the API after posix, though it has
changed over time.

The main reason it is different is because the API needs to be
asynchronous. In my opinion, simply slapping a callback to the end of
each function in posix does not make for a good API. I'm sure others
disagree and I'm open to such proposals. I think a similar approach
was taken when developing the filesystem API from google, and I'm
personally not a big fan of it.

http://www.w3.org/TR/file-system-api/

The second reason, and one that I suspect is more controversial, is
that we wanted to create an API that was simpler to get wrong. This is
why the API for example only supports exclusive locking. This way the
user opening a page in two tabs has a lower likelihood of the two
pages writing to the file at the same time and corrupting the file.

What's sort of terribly hard with the web is that effectively all
webcontent is running as multiple simultaneous processes. Yet exposing
developers to the complexities of mutexes and locks is a pretty
terrifying idea. Fortunately there is little shared state between
these processes which means that most APIs are unaffected by this
fact. But for APIs that do expose such shared state, like local
storage APIs, this is a tricky design aspect.

This definitely didn't affect the design as much though. The
asynchronous issue had a much larger influence.

The security aspect has actually *not* affected the filesystem API
design at all. The target with this API has been sandboxed filesystem
which means that they are no more security sensitive than
localStorage.

In Firefox OS we do use a filesystem API (an old incarnation of the
current draft) to access files from the user's filesystem. But even
there the filesystem API itself wasn't affected by the security model.
We were able to isolate the security issues to the function providing
access to the filesystem root instead.

All in all, the goal of this API was to *not* create browser specific
patterns. I'd love to hear what you feel is web platform specific
about the result. If we can fix that that's of course great.

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

I'm absolutely happy to have someone else do the design. But you don't
have much time. There are already at least three filesystem APIs
shipping, the Node.js one, the Google one and one in Firefox OS.

When can you have an initial draft? :-)

/ Jonas

Received on Saturday, 10 August 2013 02:02:39 UTC