[whatwg] Proposal for local-storage file management

[Jeremy Orlow]

2009/8/27 Michael Nordman <michaeln at google.com>

>
>
> 2009/8/27 Jonas Sicking <jonas at sicking.cc>
>
>> 2009/8/27 Ian Fette (イアンフェッティ) <ifette at google.com>:
>>
>> > I would much rather have a well thought-out local filesystem proposal,
>> than
>> > continued creep of the existing File and Local Storage proposal. These
>> > proposals are both designed from the perspective of "I want to take some
>> > existing data and either put it into the cloud or make it available
>> > offline". They don't really handle the use case of "I want to create new
>> > data and save it to the local filesystem", or "I want to modify existing
>> > data on the filesystem", or "I want to maintain a virtual filesystem for
>> my
>> > application, and potentially map in the existing filesystem" (e.g. if
>> I'm
>> > flickr and I want to be able to read the user's "My Photos" folder, send
>> > those up, but also make thumbnails that I want to save locally and don't
>> > care if they get uploaded, maintain an index file with image metadata /
>> > thumbnails / ... locally, save off some intermediate files, ...
>> > For this, I would really like to see us take another look
>> > at http://dev.w3.org/2006/webapi/fileio/fileIO.htm (I don't think this
>> spec
>> > is exactly what we need, but I like the general approach of "origins get
>> a
>> > virtual filesystem tucked away that they can use, they can
>> > fread/fwrite/fseek, and optionally if they want to interact with the
>> host FS
>> > they can request that and then get some sub-set of that (e.g. "my
>> documents"
>> > or "my photos") mapped in.
>> > -Ian
>>
>> If we added the ability to create File objects, which could then be
>> stored in localStorage (and WebSQL or whatever will replace it), then
>> wouldn't we basically have the functionality you seek?
>>
>> What's the difference between sticking a File in the "foo/bar/bin"
>> property on the localStorage object, vs. sicking a File object in the
>> "foo/bar/bin" directory in some FileSystem object?
>>
>>
> +1 the call to add a file system like api to the storage mix
>
> Enumerating the contents of a 'directory' is one difference. Recursively
> deleting a 'directory' is another. Checking creation/modification timestamps
> is a third. The LocalStorage big-hashmap model doesn't work well for these
> things in its current form. The hierarchical file system abstraction is well
> understand and has a long track record of usefulness.
>

Drive by comment:  I'm not saying that it'd be a replacement for a better
file system API, but it might be nice to add "range" iteration to
LocalStorage.  Of course, in order to do that, it'd need to be stored in a
tree rather than a hash table.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090827/505c1f6b/attachment-0002.htm>