Friday, July 26,
2013 11:53
I did some experiments with pouchdb inside Gecko, using passwords
and
bookmarks as my two main use cases. As Dale pointed out, if we use a
shadow database and then replicate the shadow database, we also have to
replicate from the current storage backends (password, bookmark places,
history places) into the local couchdb/pouchdb (I will use couchdb as an
abstraction anything that looks like a couchdb interface/api/db). I
wrote a draft of that code for passwords and its not really trivial. Its
probably roughly as complex as doing the same and using a custom
replication using the couchdb wire protocol into a remote couchdb on the
server.
An alternative to both would be to simply swap our current storage
backends for couchdb, in particular because some of our current storage
code is atrocious anyway (history is better, bookmarks are bad, password
backend is horrific and totally synchronous). The main problem we are
running into here is that the password manager for example is completely
synchronous. The API is of the form x = searchLogin(needle). This can't
be changed easily because there is layers and layers of APIs around this
API all across the codebase that are also synchronous. Rewriting all of
that to take a result callback would take at least a couple months. Its
righteous work, but it takes time, and it doesn't really solve a
performance problem because this code path is very rarely taken. The
solution old sync took (make a synchronous call, spin the event loop
while waiting, continue) is really terrible and we should not go down
that path.
There are 2 ways to go here
a) swap our backends for couchdb
b) swap couchdb backends for ours
Re places apis. I'm not a fan of lots of trivial wrappers of sql calls.
We can get an SQL connection to places and query it directly. This gives
you an async api and extra flexibility to add version columns, etc if
you choose to not do the shadowdb thing.
The
problem to use one database is not actually to change the password
manager's database to a couchdb. Thats trivial. The problem is that
couchdb is async, and we can't wait for the results of db queries from
within the password manager API.
For auxiliary non-places dbs using simple in-mem representations would
be a win on multiple dimensions(eg reduce development time to switching
to non-blocking apis, ability to easily use sync/async apis).
Taras
|
_______________________________________________
Sync-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/sync-dev
