RE: Request for feedback: Filesystem API

On Aug 13, 2013 6:57 PM, "Domenic Denicola" <domenic@domenicdenicola.com>
wrote:
> From: Jonas Sicking [mailto:jonas@sicking.cc]
> > 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

The sandboxed filesystem API doesn't provide access to the filesystem at
all. Implementations are essentially forced to implement it on top of a
database, possibly with the actual file data stored as separate files
(something that Gecko does for IndexedDB already). There are two main
reasons for this.

First off the differences between different platforms when it comes to
handling of "exotic" characters is complex enough that the sanest option is
to just permit a very limited set or characters. Likely this wouldn't be
popular in non-english speaking countries.

Then there is the difference in case sensitivity, which means that limiting
to lower case is the sanest way to get compatibility.

Then there is the problem with path name lengths. Especially when
considering that browsers store their data in the user profile which
already can steal quite a few characters of path length. Google
investigated this and came to the conclusion that in windows the only
length they could guarantee would work is uselessly short.

The second issue is that browsers are nervous about letting random websites
store files named screensaver.exe on the users hard drive. Even if it is
inside the browser profile folder.

So chrome already use a database back end in their API. We are planning on
doing the same.

So the whole sandboxed filesystem API is a high level API. It is being
developed at request of authors. See

https://hacks.mozilla.org/2012/07/why-no-filesystem-api-in-firefox/

Eventually we are hoping to reuse the same API once we expose real
filesystem's. But we are not there yet.

> 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"
:(.

See the link above as well as my answer to David Bruant. This feedback
doesn't match the feedback that I have gotten from developers.

Given that the two are directly opposite, I don't know how to resolve both.

One way to resolve it is to lean on the fact that Google has said that they
aren't willing to add the needed primitive to IndexedDB. That makes that
solution less attractive unless you or someone else can convince them of
otherwise.

/ Jonas