[whatwg] Proposal for local-storage file management

[Michael Nordman]

+1 ifette
A specification for traditional file-system-like api doesn't mean the
files/directories manged via that api are reflected verbatim in the OS file
system.

The distinction between a private per-origin virtual file system, and the
actual file system is a big one. I don't see any new security issues with a
'private' file system unrelated to the actual OS file system. Same issues as
apply to the existing LocalStorage apis.

There are use cases where access the actual OS file system would be useful.
Using the same file-system-like api defined for the 'private' file system is
probably a good idea when it comes to opening/closing/reading/writing files.
This would involve additional security risks, and a means of having the user
grant access to particular files and folders.


2009/8/28 Ian Fette (イアンフェッティ) <ifette at google.com>

> I don't want to make the file manager the "primary interface". I think
> that, by default, a virtual filesystem stored somewhere out of the user's
> view (either in a hidden folder in the profile, or however else the UA wants
> to implement) is fine as a majority use case. However, there are also cases
> where you do want to interact with the real filesystem. I think that
> managing photos is one example on Windows, on a mobile device it might be
> interacting with the SD card, etc.
> As for how to grant access -- I think there are paradigms that work well
> today. E.g. opening up a "file open" dialog and letting the user browse to a
> file or directory that you want to give access to. Picasa seems to have also
> gotten down the whole "Scan once" / "Watch" thing with a reasonably concise
> UI (whether you want the program to look at the folder once or have
> continuing access).
>
> Again, not trying to say that it's the primary or end-all use case, but i
> do think it is an important one that we are currently ignoring.
>
> 2009/8/28 Mike Wilson <mikewse at hotmail.com>
>
> Maciej Stachowiak wrote:
>> > Broader note: loading and then modifying existing
>> > documents in the browser might be cool. But in
>> > general, I don't see the win of making the file
>> > manager the tool to manage data created by web
>> > apps. File managers are not really that great an
>> > interface for managing information, and much of
>> > the time, something specific to the type of
>> > content is a better interface.
>>
>> That's what I think too, and my guess for the future
>> is that applications will be focusing on the actual
>> information, letting users project it in different
>> useful ways, and not force them to map it to
>> physical folders or files.
>>
>> So I say first priority is to design a first-class
>> browser storage, to make it possible to build really
>> good apps in the browser. Done right, this browser
>> storage may eventually become users' first choice
>> and ordinary files may become uninteresting.
>> (There could very well be device-specific ways to
>> exchange files between browser storage and the
>> device's own storage representation.)
>>
>> Best regards
>> Mike Wilson
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090828/cf308dd8/attachment-0001.htm>