41–50 of 87 posts
So is IndexedDB a beefier version of localStorage or does it serve a different purpose altogether?
Probably a good thing. The most complex part of Web SQL amounted to "Whatever SQLite implements", neither Mozilla nor Microsoft supported it making the standard effectively irrelevent, and I remain thoroughly unconvinced that providing an extremely thin JavaScript API to an SQL-driven database is an elegant solution to this particular problem. Presumably the W3C have decided to favour IndexedDB instead, which solves…
Why are you so wary of SQLite? As TCP/IP demonstrates, a rock solid implementation is a great help for standardization.
Probably a good thing. The most complex part of Web SQL amounted to "Whatever SQLite implements", neither Mozilla nor Microsoft supported it making the standard effectively irrelevent, and I remain thoroughly unconvinced that providing an extremely thin JavaScript API to an SQL-driven database is an elegant solution to this particular problem. Presumably the W3C have decided to favour IndexedDB instead, which solves…
Having this on disconnected devices is a very common use case. These types of applications has been written in crummy VB6 or .NET code for a long time on handheld devices, etc. I guess they will continue to be written in it then.
Key/value stores and key/value stores with ponies and rainbows (NoSQL) is not a sufficently general solution to replace the relational model.
So is IndexedDB a beefier version of localStorage or does it serve a different purpose altogether?
Local storage is just key/value queries, IndexedDB allows you to make range queries against indexes you define, so you can get eg: recent blog posts, etc.
if I want to store persist objects using localStorage, I'd convert them to JSON and store key-value. However I cannot store whole object hierarchy as it'll soon become an overkill.
so I store separate objects, and recreate relations upon retrieval manually. But I also need to maintain my own index - to know which objects I have stored under what keys.
As you see written in the spec, it was on the track to W3 Recommendation, but as every vendor who implemented it chose SQLite, there was little to do about it.
In other words, it isn't a "kill", just end of active maintainence. But spec as it is, is pretty solid. And WebSQL is here to stay in WebKit - there are just too many apps dependent on it to kill it. And no good reason to kill as there's no viable alternative on the horizon.
Summing up - WebKit (so iOS, Android and others) has it and will have it for quite a while, IE won't, FF won't too.
Earlier quoted context omitted.
For someone unfamiliar with the term, what does "web-like" mean?
An API that maps to the underlying data-structure (btree, ranges, cursors), is bar-none simpler than an API that abtracts the underlying data structure away (like any SQL does). The web was built by taking existing systems, and cutting away at them until they were so simple they barely worked. But because they were simple they could spread. IndexedDB isn't the simplest spec it could be (I think they could do-away wit…
That may be true in this specific case (I'm not saying either way), but it does not hold generally. For example, APIs involving directories and files are simpler than APIs involving inodes and blocks.
Earlier quoted context omitted.
The truth is the reason they pointed to SQLite is because the proposed API was so obscenely complicated that it was easier to point to a reference implementation than to accurately specify a standard, which points to a rather fundamental problem with the proposed standard: SQL is too damn complicated, and embedding it in browsers is a bad idea. For a web standard to succeed, you need either Mozilla or Microsoft suppo…
Why not just use SQLite? Write a small wrapper around it to isolate each website off on it's own database or set of databases. Each site corresponds to a SQLite user with a password that ONLY the browser knows.
Am I the only one that's sad about this?
From practical perspective we would be better off with Web SQL DB. Functionally it addresses everything a developer needs to create offline HTML apps. API is not perfect but you can always improve that with small wrapper libraries (like JQuery improves DOM API). You can always easily implement IndexDB-like API on top off SQL if you really want that. The opposite is probably possible but much more difficult.
Also I think IndexDB might turn out to be yet another compatibility headache because everybody will be creating their own implementation (I'm pretty sure there will be at least 3 - Microsoft, Mozilla & Webkit). It's a speculation but most likely this wouldn't be an issue with Web SQL DB because everybody would just use the same SQLLite backend.
And worst of all, this is delaying progress of web applications. Lack of solid cross-browser client-side storage solution is the last big gap for next generation of web applications. If everybody had just agreed on SQLLite we could be there today... now it's still unknown when we will get there.
I have read the comments in Mozilla's thread http://hacks.mozilla.org/2010/06/beyond-html5-database-apis-... they clearly don't give a damn about what the users want.
They should have just agreed on a simple subset of SQL instead of going NoSQL, but apparently that wasn't good enough for them, waiting a decade more for something to store data in is probably better.
I personally love the concept of NoSQL, it's just that IndexedDB needs a few more years, which means it will probably even miss IE10.