Re: [whatwg] Intent of the FileSystem API

On 2/28/2011 4:10 PM, Eric Uhrhane 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.
...
>> 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.

It's much easier to send a query via IndexedDB to "list all files" in a 
directory
mask, than it is to build up the same thing using getDirectory.

I'm quite happy with File, FileWriter, and so forth.

It's much easier/quicker to post a binary blob at an arbitrary path 
using a data store, than it is going through full file system
semantics; a bunch of create directory and file calls.

For scalability, you've got Amazon S3 and Google Storage as data store 
models.

I target the old WebSQL, localStorage, file system,
IDB and remote services, to stash images and metadata.

IDB has been the easiest to support, as the others generally require 
more work to stash metadata information,
and have uncertain locking.


>> 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.
I'm supportive of a virtual FS for the temporary file system, but
using a real sandbox for the permanent system.

I'm sure we'll get there eventually, serving both 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.
What's the hold up? Working with base64 encoding is slow.
createObjectURL is nice.

> 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.
Yes, I submitted that feedback :-)

My understanding is that it's quite reasonable to get longer paths than 
the current 255 bytes.
Keep in mind, that includes the whole path to the AppData profile directory.

There are certainly issues in old copies of windows, but I think they've
been addressed since.

> speed of access and ease of modification, but we'll be storing the
> paths in an internal database.
I did the same on the file system as well, as I needed that flexibility
to get around the various constraints.

I kept original file names, which caused some problems with the 255 byte 
limit.

stashed the file in
sha1hash.substr(-2) + '/' + sha1Hash + '/' originalFilename
with metadata in
sha1hash.substr(-2) + '/' + sha1Hash + '/' metaDataHash + '/entry.txt'

The metadata entry.txt files are in there as a precaution and for 
transparency
if the user is accessing things outside of the app.

..

Would your virtual FS be up to including a "Dropbox" style directory,
where users could copy files into, and they'd be accessible to the FS api?

That's also how I modeled mine, including a Dropbox directory underneath
it all, for users to easily copy files into.

In some cases, it's much easier to drag/drop a hundred files into the 
directory,
through the system file manager. Also allows for the OS to treat the dropbox
as a queue: the browser doesn't need to be running to add items to the 
queue.



> 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.
>
Well it sounds like there's definitely a case for "mounting" an existing 
FS/directory,
and there's certainly a different case for using a virtual FS for 
efficiency.


-Charles

Received on Tuesday, 1 March 2011 01:00:31 UTC