+1 ifette<div><br></div><div>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.</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><br><div class="gmail_quote">2009/8/28 Ian Fette ($B%$%"%s%U%'%C%F%#(B) <span dir="ltr"><<a href="mailto:ifette@google.com">ifette@google.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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.<div>
<br></div><div>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).</div>
<div><br></div><div>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.<br><br><div class="gmail_quote">2009/8/28 Mike Wilson <span dir="ltr"><<a href="mailto:mikewse@hotmail.com" target="_blank">mikewse@hotmail.com</a>></span><div>
<div></div><div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Maciej Stachowiak wrote:<br>
> Broader note: loading and then modifying existing<br>
> documents in the browser might be cool. But in<br>
> general, I don't see the win of making the file<br>
> manager the tool to manage data created by web<br>
> apps. File managers are not really that great an<br>
> interface for managing information, and much of<br>
> the time, something specific to the type of<br>
> content is a better interface.<br>
<br>
</div>That's what I think too, and my guess for the future<br>
is that applications will be focusing on the actual<br>
information, letting users project it in different<br>
useful ways, and not force them to map it to<br>
physical folders or files.<br>
<br>
So I say first priority is to design a first-class<br>
browser storage, to make it possible to build really<br>
good apps in the browser. Done right, this browser<br>
storage may eventually become users' first choice<br>
and ordinary files may become uninteresting.<br>
(There could very well be device-specific ways to<br>
exchange files between browser storage and the<br>
device's own storage representation.)<br>
<br>
Best regards<br>
<font color="#888888">Mike Wilson<br>
<br>
</font></blockquote></div></div></div><br></div>
</blockquote></div><br></div>