Re: [whatwg] Intent of the FileSystem API

Sorry--I meant to push this over to public-webapps, as Ian suggested.
[+cc public-webapps, whatwg->BCC]

On Mon, Feb 28, 2011 at 4:10 PM, Eric Uhrhane <ericu@google.com> wrote:
> On Mon, Feb 28, 2011 at 2:54 PM, Charles Pritchard <chuck@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
>

Received on Tuesday, 1 March 2011 00:42:07 UTC