Things missing from Arun's File proposal as is, off the top of my head:<div><br></div><div>a) a directory structure (someone would have to build one on top of it... not critical, but not ideal)</div><div>b) Ability to store it not in localStorage in some hidden directory, but on the part of the filesystem the user is familiar with (e.g. if I edit a picture, I don't want to store it in localStorage tucked away under "local settings\user data\...", I want to save it in /home/ifette/photos/blah.jpg). Don't make the browser a silo.</div>
<div>c) ability to map in a directory and make sense of that. I want Picasa / Flickr / Facebook to be able to see "oh look, there's a new file in /home/ifette/photos/ - let's act on that.")</div><div>d) Ability to read/update parts of the file. Could be used similar to blob builder for building up a form post that I then send off. Or could be used to manage an offline mail database, assuming I don't want to shove my mail into a sqlite database. For this it's desirable that I be able to efficiently fseek(), fread(), and fwrite() segments of the file.</div>
<div><br></div><div><br></div><div><br></div><div><br></div><div><br><div class="gmail_quote">2009/8/27 Jonas Sicking <span dir="ltr"><jonas@sicking.cc></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
2009/8/27 Ian Fette (イアンフェッティ) <<a href="mailto:ifette@google.com">ifette@google.com</a>>:<br>
<div class="im">> I would much rather have a well thought-out local filesystem proposal, than<br>
> continued creep of the existing File and Local Storage proposal. These<br>
> proposals are both designed from the perspective of "I want to take some<br>
> existing data and either put it into the cloud or make it available<br>
> offline". They don't really handle the use case of "I want to create new<br>
> data and save it to the local filesystem", or "I want to modify existing<br>
> data on the filesystem", or "I want to maintain a virtual filesystem for my<br>
> application, and potentially map in the existing filesystem" (e.g. if I'm<br>
> flickr and I want to be able to read the user's "My Photos" folder, send<br>
> those up, but also make thumbnails that I want to save locally and don't<br>
> care if they get uploaded, maintain an index file with image metadata /<br>
> thumbnails / ... locally, save off some intermediate files, ...<br>
> For this, I would really like to see us take another look<br>
> at <a href="http://dev.w3.org/2006/webapi/fileio/fileIO.htm" target="_blank">http://dev.w3.org/2006/webapi/fileio/fileIO.htm</a> (I don't think this spec<br>
> is exactly what we need, but I like the general approach of "origins get a<br>
> virtual filesystem tucked away that they can use, they can<br>
> fread/fwrite/fseek, and optionally if they want to interact with the host FS<br>
> they can request that and then get some sub-set of that (e.g. "my documents"<br>
> or "my photos") mapped in.<br>
> -Ian<br>
<br>
</div>If we added the ability to create File objects, which could then be<br>
stored in localStorage (and WebSQL or whatever will replace it), then<br>
wouldn't we basically have the functionality you seek?<br>
<br>
What's the difference between sticking a File in the "foo/bar/bin"<br>
property on the localStorage object, vs. sicking a File object in the<br>
"foo/bar/bin" directory in some FileSystem object?<br>
<br>
Note that the latest HTML5 drafts allow for storing File objects in<br>
localStorage.<br>
<font color="#888888"><br>
/ Jonas<br>
</font></blockquote></div><br></div>