W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2011

[whatwg] Using requestFileSystem to setup mounts

From: Bronislav Klučka <Bronislav.Klucka@bauglir.com>
Date: Wed, 21 Dec 2011 09:10:07 +0100
Message-ID: <4EF1945F.4060608@bauglir.com>
Hi,
what about

window.MOUNT_ONCE
- mount only for current session
- would open select folder dialog

window.MOUNT_ALWAYS
- mount for all time (or to be more precise for the time of life time of IndexDB, cookies, etc).
- user have to give explicit permission for this and only after this permission is given, select folder dialog is opened
- delete browser data (IndexDB, cookies, etc) would only remove permission to access such folder, not it's content

FileSystem interface has property name, so programmers could distinguish among several FileSystem object and could store those somewhere (e.g. LocalStorage).

if folder, which is already mounted, was selected from "select directory" dialog, than already existing FileSystem object would be returned corresponding with that directory (e.g. fs.name = '123-456-abc' is created once "c:/tmp" is requested and that FileSystem object would be always returned if the same folder is requested). Name property would than probably have to be some kind of hash of the original directory path (so it's unique across users desktop file system)

This could be very important feature, because currently there is no (real) persistent storage, even when window.PERSISTENT file system is created, data can be removed by just users desire to delete cookies (browser generally do not allow to specifie what kind data should be removed [cookies/indexdb/websql/app cache/local storage/etc.] At this point, it's quite a pain to e.g. create export file from data you already have in browser without accessing server...


The only problem I see with this approach is that it does not allow very common screnario: "save file as" in regular desktop app way:
1/ user clicks "save"
2/ "save as" dialog is opened and file (file name with path) is returned
3/ app creates file based on that path
4/ app writes data to file

having only FS mounted to directory would require:
1/ have some<input type=text>  where user writes file name
2/ user types file name to that input
3/ user clicks "save"
4/ "select folder" dialog is opened, FileSystem is returned in callback
5/ app creates file based on returned FileSystem and file name from step 1
6/ app writes data to file

in desktop app scenario user specifies whole file path, in requestFileSystem scenario, user would have to specifie file name and then path... quite a different behaviour from what users are used to (users are used to desktop app behaviour even in browser when downloading file from internet)...

B.

On 21.11.2011 15:10, Kinuko Yasuda wrote:


>> 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.
>
>
>> -Charles
>>
>>
Received on Wednesday, 21 December 2011 00:10:07 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:38 UTC