- From: Eric Uhrhane <ericu@google.com>
- Date: Mon, 28 Feb 2011 16:41:23 -0800
- To: Charles Pritchard <chuck@jumis.com>
- Cc: Web Applications Working Group WG <public-webapps@w3.org>
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