On desktop, moving history+bookmarks from SQLite to CouchDB seems like a rather large undertaking.
Gavin On Fri, Jul 26, 2013 at 1:30 PM, Andreas Gal <[email protected]> wrote: > > Nobody is asking to move all core services. We are talking about history, > bookmarks and passwords, for now. > > Andreas > > > Mark Finkle wrote: > > > > ________________________________ > > > 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. > > Using a custom replication using CouchDB wire protocol has a benefit of not > needing to convert the entire application to use CouchDB as the backing > datastore. Given that the effort could be "roughly as complex", I'd rather > explore the custom replication and not trade lock-in to one datastore > (SQLite) for another (CouchDB). > > > 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. > > Let's not underestimate the time required to move from SQLite to CouchDB for > all core data in Firefox. > > > > _______________________________________________ > Sync-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/sync-dev > _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
