[whatwg] Using requestFileSystem to setup mounts

On 11/21/11 6:10 AM, Kinuko Yasuda wrote:
> Hi, thanks for your comment!
>
> On Sun, Nov 20, 2011 at 5:54 AM, Charles Pritchard<chuck at jumis.com>  wrote:
>>
>> // Proposal, using DataTransfer with rFS:
>> input.ondrop = function(e) {
>>   window.requestFileSystem(e.dataTransfer, 0, cb);
>> }

>> There's some slight room for delaying the population of
>> e.dataTransfer.files, by using a long-running for loop, or something of that
>> sort.  Otherwise,
>> if rFS is used, .files will not be populated. This avoids directory
>> traversal overhead while using rFS for permissions management.
> I may not be quite following this point.  I might be missing
> something but isn't it same with the case where the app script
> just checks the existence of the new field like .entries and then
> falls back to .files if the field doesn't exist?
> If .entries is supported the script doesn't need to touch the
> .files field thus the UA does not need to populate the .files
> field (though I guess if the UA supports .files field it'd start
> populating the field before it is actually accessed).

Neuter the .files object early in the event loop so that FileList does 
not need to be populated

// .files is neutered after rFS.
  window.requestFileSystem(e.dataTransfer, 0, cb);
  e.dataTransfer.files; /* this will throw an error. */

>> Additionally, I might pass window.MOUNT into rFS, which may prompt the user
>> to select a mount point, bypassing<input>    altogether.
> This sounds cool, and I think eventually we want to have some explicit way
> to mount an arbitrary directory in a way this (requestFileSystem(MOUNT)),
> but what concerns me most in this generalized API is how we should
> define the lifetime of the mount'ed filesystem.

Conservatively have Entry.toURL return undefined, or a new prefixed value.

Undefined is fairly safe and is the default case for file:/// with 
webkitURL.createObjectURL
Users can still run .file and create a blob url.

An extended Entry.toURL returns the filesystem: url prefix:
"filesystem:blob:random:/path/".

The lifetime of the filesystem is undefined and may expire at any time.
> In the drag-and-drop context it's clear that the permission and namespace
> must go away once the context goes away.  But for more generic and
> extended usage (I assume requestFileSystem(window.MOUNT) would
> imply more generic usage) probably we should be more careful about how
> long and when the filesystem lifetime should expire.  Maybe we could collect
> real usage with the limited mount support and then move things forward
> incrementally.  Wdyt?
Afaik, the requestFileSystem API is used by extension developers and 
browser extensions are a good place to carefully roll out new APIs.

requestFileSystem(window.MOUNT) could simply trigger directory selection.

// Basic polyfill for requestFileSystem(window.MOUNT)
var input = document.createElement('input');
input.type = 'file';
input.setAttribute('webkitdirectory', '');
input.click();

// HTML polyfill of input type="file" and mount points:
<input type="file" onclick="requestFileSystem(window.MOUNT); return 
false;" />


-Charles

Received on Monday, 21 November 2011 13:14:46 UTC