- From: Charles Pritchard <chuck@jumis.com>
- Date: Wed, 06 Apr 2011 18:49:41 -0700
- To: Ryan Fugger <arv@ryanfugger.com>
- CC: public-webapps@w3.org
On 4/4/2011 10:15 AM, Ryan Fugger wrote: >> That's not the only reason. Mozilla laid out others ten months ago: >> https://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-road-to-indexeddb/ > Mozilla's plan appears to be to implement IndexedDB on top of SQLite, > and then encourage developers to build SQL in javascript on top of > IndexedDB. That seems like a ludicrous hoop to jump through to avoi They have no intention of exposing SQLite to the untrusted environment, having it in a standards doc wouldn't change that. SQL has been done-before in JS, I don't see what Mozilla's enthusiasm about an SQL+IDB layer is about. http://code.google.com/p/trimpath/wiki/TrimQuery I'm a big fan of sqlite. I love public domain software. I think it's a great idea. And this is no slight on sqlite; it does not implement some exotic features that really make SQL powerful. Windowing functions really cut down on code: http://developer.postgresql.org/pgdocs/postgres/tutorial-window.html http://developer.postgresql.org/pgdocs/postgres/functions-window.html I do like the RelationalDB idea being floated, I'd like to see more energy put into that proposal. It looks like something that's easier to implement on top of JS objects, SQLite, or ArrayBuffer, than starting with the SQLite SQL dialect. It's still complicated, in that it may easily be fed large joins that will grind the computer to a halt, so that's something that needs to be taken into account. I'm happier working with IDB than SQLite. I'm happier with IDB than the FileSystem API, too. It's just easier for the items I work on. And I'm happy that webkit has SQLite available in their public api, because I've fallen back to it many times for data storage. But I just use it in key value pair. -Charles
Received on Thursday, 7 April 2011 01:50:04 UTC