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

Reply via email to