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

2013/2/11 Robin Berjon <robin@w3.org>

> 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.
>
> This is pretty much already done, look at PouchDB. Something I have been
thinking is to wrap IndexedDB API to provide these additional events and
borrow some ideas from PouchDB how to allow multiple windows listen these
changes (they use WebStorage for the communication and listen certain
changes).


>
>  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).


Done that already, though there hasn't been much discussion around the
topic.



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



-- 
Miko Nieminen
miko.nieminen@iki.fi
miko.nieminen@gmail.com