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

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