On 09/26/2012 01:32 AM, SULLIVAN, BRYAN L wrote:
*From:*Maciej Stachowiak [mailto:m...@apple.com]
*Sent:* Tuesday, September 25, 2012 2:59 PM
*To:* Glenn Maynard
*Cc:* Eric U; o...@pettay.fi; public-webapps@w3.org
*Subject:* Re: Moving File API: Directories and System API to Note track?
Hi Glenn,
I read over your points. But I don't think they would change Apple's
calculation about exposing an API to the real user filesystem in Safari,
particularly as specified. I do think that my more minimal API might also be a better fit
for the "real filesystem" use case, as it removes a bunch of
unnecessary levels of indirection and abstraction that exist in the other
proposals. But I think it is unlikely we would expose that aspect.
We are still open to solving the "sandboxed local storage area" use case, with
a more minimal API. But first we'd like to understand why those use
cases can't be solved with targeted additions to IndexedDB (see forked thread).
Can IndexedDB support the use case of managing a media or document library on
the local device, in which the size of library can run into hundreds or
files and gigabytes of storage?
I don't see any technical problems with that.
Local storage of media is one of the key capabilities needed to enable
HTML5-based offline media players as a
realistic option. If the browser can effectively provide a virtual filesystem
with performance characteristics equivalent to the underlying OS, then
perhaps IndexedDB may suffice for filesystem access. But which browsers intend
to support that level of functionality via IndexexDB?
Isn't that part of IndexedDB, to be able to store files efficiently in it. So I
would assume all the implementations will
support that.
