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

Hi Miko,

On 10/02/2013 23:37 , Miko Nieminen wrote:
> CouchDB has concept of views
> that help on this matter, but with IDB those needs to be created
> separately when indices are not enough or you need to go over object
> store boundaries.

One question I've been having is "how hard would it be to replicate 
Couch atop IDB?" (Probably just using something like Cradle's API rather 
than exposing a full-fledged HTTP API.) I've only gone so far as 
thinking about the basics and no actual code but I think it ought to be 
possible. To me, that would be a good validation that at least the 
feature-set is correct.

> When comparing to CouchDB, something I'm missing is ability to
> subscribe events when there are changes in the database. I was somewhat
> disappointed realizing that there is no similar mechanism in IDB. What
> I would like to see is Object Store events for new, modified and
> deleted objects. This would allow writing generic library for data
> replication or creation of dictionary for global or database level
> search. As an addition these events would provide easy way of keeping
> multiple windows in-sync. There are ways go around lack of these
> events, but not very elegant ones.

That's a very good piece of feedback. If you have time, it would be 
great if you were to send it to WebApps (where work on IDB is actually 
done).

> Other shortcoming is the lack of UUID or other globally/universally
> unique IDs as object keys. When thinking about NoSQL world, having these
> feels just obvious and I'm amazed that this is not the default ID format
> for IDB or at least required as an alternative by the specification.
> This is a must to have feature for creating proper synchronization
> libraries. You can use something like uuid-v4.js and generate your ids
> by hand, but as far as I know uuid-v4.js trusts Math.random() that has
> its own issues and same applies to all UUID Javascript implementations.
> So in the end it would be nice to have browser provided UUIDs that are
> working properly and key generator that provides UUID based ids.

That's very true. Hopefully, something like this can help:

     http://www.w3.org/TR/WebCryptoAPI/#RandomSource-interface

> So, I think IDB is fairly nice API and I don't really understand all
> the criticism when use of SQL based solution would be much more
> complicated to implement and use, and current IDB API is easy to learn
> by anyone who has experience of Javascript combined with jQuery or
> similar libraries. Another problem with SQL based solution would be the
> question of which version of the standard to match or would this be yet
> another SQL standard version.

As I said previously, I think that while there are indeed some aspects 
of IDB that are ugly, most of the criticism comes from the fact that 
developers expect something really simple and off the shelf, and aren't 
overall happy with a lower-level API. I would be surprised if that hole 
weren't plugged by libraries now that we're starting to see better interop.

I certainly agree that something based on SQL would be horrible :)

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Monday, 11 February 2013 14:22:42 UTC