[whatwg] Intent of the FileSystem API

[Eric Uhrhane]

On Mon, Feb 28, 2011 at 2:54 PM, Charles Pritchard <chuck at jumis.com> wrote:
> I'd like some clarification on the intent of the FileSystem API:
> requestFileSystem permanent, getDirectory and getFile.

The FileSystem API has several goals.  Some of them are targeted by
the current spec, and some have been discussed, but put off until
later.  We didn't want to take on too much in a single pass [hence the
three layers of file-related specs so far].

> Are they intended to directly pass through to the host operating system, or
> are they just programming constructs?

The intent for the local sandbox described in the current FileSystem
spec was that that would be up to the implementer.  If a UA implements
it as a passthrough, the files could then be accessible to client-side
apps as well as the web.  That's reason for the restrictions in the
"uniformity of interface" section--if you're going to expose the true
local filesystem, you run into different restrictions on names and
paths on each platform, and we want code that uses this API to run
everywhere.  However, we've been running into some issues in this area
with our implementation--more on that below.

> They're not particularly easy to use, compared to the IndexedDB data store,

I find files to be easier to use than databases, but I'm clearly
biased ;'>.  However, that's not really the point.  Files and
databases serve different needs, and various use cases are better
served by each than the other.  If you want transactions or indexing,
you want IDB.  If you want fast, mutable binary blobs with persistent
URLs, you want FileSystem.

> but if they are OS level commands,
> then they do help with usability of a web app with the rest of the OS: with
> managing files directly from the OS file manager.
>
> Is the FileSystem API intended to expose a folder on the host operating
> system, or is it just an abstraction
> which can be bolted onto any data system (such as, using SQLite as a
> backend, as appCache and IndexedDB do)  ?

While the current API could in theory be implemented either way, there
have been many requests for expansions to the API that would allow for
access to directories outside the sandbox, e.g. giving Flickr access
to "My Photos".  While that's not yet been specced, that would clearly
require real pass-through access and real file names.  The rest of the
API could of course be identical, and I hope that eventually it will
serve both use cases.

> Are there any plans of reviewing/visiting efficient File/Blob support in
> indexeddb?

I can't speak for the indexedDB developers, but the last I heard
on-list, they were at least hoping to support immutable Blobs, but not
soon.

More on those portability issues:

We've been implementing the current FileSystem API spec in Chrome, and
had planned that our implementation of the sandbox would be just a
passthrough to a directory under the user's profile.  We've been
testing that out, currently only allowing access to extensions and
apps, but we've gotten feedback that long profile paths are causing a
problem on Windows.

Our current implementation on Windows uses the standard API calls that
limit paths to 256 characters long.  If your profile directory is
deeply nested [e.g. because you have a really long username], code
that works for your friend might not work for you.  We thought we'd
fix that by using the long-path APIs that allow creation of paths up
to ~32k chars long.  However, it seems that, even though Windows has
these APIs, most programs don't use them.  In particular, Windows
Explorer doesn't, so it chokes on them and can't delete files in
directories with long names.  We think it would be really awkward if
Chrome were creating directories under its profile directory that
couldn't easily be deleted, so we're going to start virtualizing our
filesystem implementation.  We'll still have real native files for
speed of access and ease of modification, but we'll be storing the
paths in an internal database.

This then brings up the question of whether one can specify a uniform,
useful interface for the API that *doesn't* require virtualization of
the filesystem, but I'll be bringing that up in another thread.

     Eric