W3C home > Mailing lists > Public > www-tag@w3.org > February 2013

RE: IndexedDB, what were the issues? How do we stop it from happening again?

From: SULLIVAN, BRYAN L <bs3131@att.com>
Date: Thu, 7 Feb 2013 15:42:50 +0000
To: "www-tag@w3.org" <www-tag@w3.org>
Message-ID: <59A39E87EA9F964A836299497B686C351096DE04@WABOTH9MSGUSR8D.ITServices.sbc.com>
> And one more question I have, is it a goal or failure to have to rely on other's to build JS libraries on top of a standardised 
> API to make it useful? It seems that it was the goal of IndexDB that it would not be developer friendly:
>
> "The goal of IndexedDB was to allow multiple different query processors to be built in JS. We expected few people to use it > directly."
> https://twitter.com/adrianba/status/236249951049502720

>
> What do you think?
>

I can't speak to the technical aspects of how it's designed, but can underscore that use cases such as we are trying to pursue in Web & TV (media recording & download) will depend heavily on the ability to store large amounts of media *somewhere*, and build effective media gallery frameworks on top of the storage. It's a bit disconcerting to hear such complaints and comments re intent about IndexedDB (assuming they are well-founded) when IndexedDB is being held up (at last TPAC, in several discussions) as the reason we no longer need a File Writer or FileSystem API in Webapps.

We need effective, efficient, robust content storage facilities for the Web platform, *now*. The question is whether this will be *in* the Web platform, or layered over the top e.g. using XHR2+CORS and locally running filesystem-access servers. I hope W3C can help us support both options.

And of course I'm talking about use in *browsers* here, not the SysApps APIs which will clearly address these needs for Web-based device apps.

Thanks,
Bryan Sullivan 
Received on Thursday, 7 February 2013 15:43:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 7 February 2013 15:43:39 GMT