- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 28 Aug 2009 00:55:35 -0700
2009/8/27 Ian Fette (????????) <ifette at google.com>: > Things missing from Arun's File proposal as is, off the top of my head: > a) a directory structure (someone would have to build one on top of it... > not critical, but not ideal) > 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. > 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.") > 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. Ah, now I follow what you are requesting. Basically the ability to not just hook into some virtual directory of files, but rather the normal file tree as seen by the user on the Desktop/Documents folder/Images folder/etc. And with that, not just the ability to read these files, but also write to them. I see two major problems with this: 1. Security How to do all this while protecting users and their data 2. Cross platform differences Different platforms have different directories and directory structures for storing the photos/music/documents/etc. I agree that what you describe would be useful. I have no idea how to solve the above two problems (especially the first one). Looking forward to proposals ;) / Jonas
Received on Friday, 28 August 2009 00:55:35 UTC