- From: Mike Wilson <mikewse@hotmail.com>
- Date: Fri, 28 Aug 2009 20:47:23 +0200
Right, trying to answer on-topic ;-) I guess if the spec doesn't mention anything about where localStorage is persisted, it leaves it up to every browser to decide whether to ask the user or use a default location. Earlier I didn't think of the possibility of localStorage data being stored in different locations for different apps, but that might be a good idea. I can see both good and bad sides of this; it's good with more control for expert users that want to put data in very specific locations. On the other hand I would also want to build apps that don't force users to make decisions about files and folders at all, they should "just work". Maybe the storage decision could be "high level", offering simplified alternatives like - browser's default storage location - user account's "documents" location - that SD card you just inserted There still is the problem that Michael Nordman mentioned; there is no way to identify specific applications's data so f ex all apps under www.google.com would be routed into the same file. Will I be able to make collective decisions about data for collections of apps like that? Maybe. Or it will be worked around by even more vanity host names. (importantdocs.google.com, privatedocs.google.com, ... ;-) Best regards Mike Jens Alfke wrote: > There's some feature-creep going on in this thread. I think a > filesystem API is a good feature for the future, but the immediate > issue is with the pending local-storage API: how to balance > applications' legitimate needs for permanent local storage > with users' > legitimate needs to manage disk usage and backups. I don't think > that's an issue we can put off until HTML6 or whenever. > > Yes, my suggestion does involve the filesystem, but not in a way > that's visible to the web-app. The app simply sees a persistent key- > value store as currently spec'ed; it has no idea where in the > filesystem the user has chosen to put it. Whereas the user just > decides on a parent folder (and maybe a quota), without > having access > to the individual records inside. > > The purpose is just for the user to have some control of whether to > give the app storage at all, and if so where to put it, and the > ability to manage that storage via the regular file manager UI. (Or > for platforms that don't have such a UI, like the iPhone, > some kind of > flat list of web-apps.) > > -Jens
Received on Friday, 28 August 2009 11:47:23 UTC