- From: Eric Uhrhane <ericu@google.com>
- Date: Mon, 28 Feb 2011 16:10:55 -0800
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
Received on Monday, 28 February 2011 16:10:55 UTC