Re: [whatwg] Intent of the FileSystem API

On Mon, Feb 28, 2011 at 4:59 PM, Charles Pritchard <chuck@jumis.com> wrote:
> 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 don't think it's likely that we'll want to have different APIs for
temporary vs. persistent storage, in the origin-specific sandbox.  But
if you mean a different API [different path limitations, anyway] for
the sandbox vs. other "mount points" such as "My Photos", then yes, I
think that makes sense.

> 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?

No.  That'd have to wait for the proposed expanded API that would
allow for other mount points.

> 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 18:10:58 UTC