indexeddb and object store events

Asking my previous question again.

There has been some discussions in www-tag list about IndexedDB API as an
addition to discussion happening here. At www-tag, I was instructed to
return back to this list with my question.

There seems to be worry over IDB that it is too low level API and too
complicated or verbose to use by someone not having degree in computer
science. I do understand this worry, but at the same time I haven't seen
any proper suggestions for better API than what we have and to be honest
I'm quite happy with the current API. I don't feel it is too verbose
especially when I see that the verbosity improves readability in this case.
Only part that I feel could possibly be simplified is the use of
transactions. Though I don't see any other solution for this than auto
transactions and that kind of mechanism would probably have its own issues
and would complicate implementation of IDB and I definitely don't want to
see transactions going away. Other than that, I don't really think that the
API requires much more simplifications and if it does, I don't really know
how to do that. I think slightly harder lower level API at this point is
much better than over simplified higher level API that limits use of too
much. On top of lower level API you can write generic abstraction layers in
Javascript, but not other way around. In the future version of the API we
can then go back and see what kind of issues different abstractions are
trying to solve and then add needed parts in the standard.

But to the actual topic. As I raised earlier, main true problem with IDB is
that I cannot listen changes in a object store. This does not feel that
important when coming from SQL world, but after using other NoSQL databases
and especially when thinking about rest of the web APIs, it doesn't make
much sense not to have these events. WebStorage API defines this kind of
mechanism and I feel it is quite odd that IDB does not.

I have three quite clear use cases for this one that could be much
simplified with these events:
1) I want to create synchronization library that is generic component
providing IDB client to server sync. For example I have REST API for data
in my service and I want to keep my clients in sync with the sevice over
web sockets. To create this I need to wrap local modification requests to
notify my library about the changes. In other words, I need to make my
other components to know about this sync components, instead just including
the component and telling which object stores to keep in sync and then this
component could listen for new objects, modifications and deleted objects
and notify service about these changes or it could just modify database
when service notifies of change and my application component would see
modification through object store events.
2) I want to create search component for so that I can index all words
found in my objects. For example I create notes app where I want to index
all words found in all notes and map those to my note objects. Then I want
to use key range search for searching all notes that have words starting
with my search term. This is a bit naïve example and it can be implemented
by adding the code into my modification places, but again I would like to
have generic component that does the indexing by listening these changes
and then just include this library in my app.
3) I want to keep multiple windows in sync with changes in my objects.
There are lots of approaches to have this, by using local storage as
communication channel or create postMessage channel, but this is all just
additional code that should not be needed in the first place and I need to
hook my code that makes modifications to make these notifications instead
just listening changes in my object store and hooking my HTML updates to
these change events.

To simplify implementation of these example cases, I would like to listen
change events through object store so that I know when object is added,
modified or deleted. I think these events should be launched right after
transaction is completed. This raises some questions that how about order
of these events or should we provide some kind of change chunk mechanism
like for example CouchDB has when listening change notifications. At the
first version, I wouldn't solve these issues. It should not matter in which
order these events come as long as mid transaction changes are not
notified. Add + put should be notiified as add, put + delete should be
notified as delete, and multiple puts should be notified as single put
showing the last state. Should we have multiple objects in one change, is a
good question.

So far I haven't got other feedback than this is fairly good idea and
probably should be included in the official API, but is it stillpossible to
get this kind of changes included in the API or am I too late with this
request? If it is possible to have this change, is there anything I can do
to help it getting forward? I'm working on reference implementation in
Mozilla's codebase and I feel I'm quite close getting the first version
working, but I'm hacking it on my free time and I have no previous
experience from Mozilla's code so the progress is somewhat slow.

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