W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2012

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

From: SULLIVAN, BRYAN L <bs3131@att.com>
Date: Thu, 4 Oct 2012 12:32:22 +0000
To: "olli@pettay.fi" <olli@pettay.fi>
CC: Maciej Stachowiak <mjs@apple.com>, Glenn Maynard <glenn@zewt.org>, Eric U <ericu@google.com>, "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <59A39E87EA9F964A836299497B686C351003622E@WABOTH9MSGUSR8D.ITServices.sbc.com>
> -----Original Message-----
> From: Olli Pettay [mailto:Olli.Pettay@helsinki.fi]
> Sent: Thursday, October 04, 2012 3:48 AM
> To: SULLIVAN, BRYAN L
> Cc: Maciej Stachowiak; Glenn Maynard; Eric U; public-webapps@w3.org
> Subject: Re: Moving File API: Directories and System API to Note track?
> 
> On 09/26/2012 01:32 AM, SULLIVAN, BRYAN L wrote:
> > *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?
> I don't see any technical problems with that.
> 
Other than hard limits on storage per origin and how the virtual filesystem would be organized and managed, neither do I, but I am not an expert in browser design, that's why I asked the question. If there are no technical problems, anyone have thoughts on how soon we can expect to see browsers that provide a virtual filesystem implementation based upon Indexed DB?

> 
> > 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.

I don't think specific efficiency objectives are a normative requirement of Indexed DB, but the question was more whether browser vendors would claim that their Indexed DB implementation will provide performance equivalent to the underlying OS. Apart from the technical challenges, it's unrealistic to use Indexed DB for this purpose if the performance cannot match the underlying OS.
Received on Thursday, 4 October 2012 12:33:21 GMT

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