W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

RE: Moving File API: Directories and System API to Note track?

From: SULLIVAN, BRYAN L <bs3131@att.com>
Date: Tue, 25 Sep 2012 22:32:53 +0000
To: Maciej Stachowiak <mjs@apple.com>, Glenn Maynard <glenn@zewt.org>
CC: Eric U <ericu@google.com>, "olli@pettay.fi" <olli@pettay.fi>, "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <59A39E87EA9F964A836299497B686C3510018A82@WABOTH9MSGUSR8D.ITServices.sbc.com>
From: Maciej Stachowiak [mailto:mjs@apple.com]
Sent: Tuesday, September 25, 2012 2:59 PM
To: Glenn Maynard
Cc: Eric U; olli@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? 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?
Received on Tuesday, 25 September 2012 22:34:13 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:54 GMT