The CouchDB protocol has some properties where I am not convinced that its a good fit for us. Amongst others, each document has an unlimited history that is tracked locally. This is actually needed for multi-party replication. I would like to understand how we will deal with this. Lets say we use a shadow copy in couchdb. What do we do with history? This question is particularly important to get right, because technically speaking for a sync scenario where you have 1 server that replications with many clients, but each of those clients only replicates with that 1 server, we don't really have to maintain any history in the clients to be able to replicate, if I understand the couchdb replication protocol correctly. With pure pouchdb we would be storing that history for no reason, using up disk space beyond the mere lets-store-everything-twice property of a shadow copy.
Last but not least, if we find a way to eliminate keeping a history for each doc (and instead just maintain a change log with the last changed value waiting for outgoing replication, not the historic changes), we could consider a 4th architecture where we wrap our existing database into a couchdb "view" for the lack of a better word. We would basically ad specific adaptors to couchdb for specific storages. There could be a pouchdb.password-manager.adaptor.js in our pouchdb that exposes the content of the password manager database as if it was stored in a pouchdb/couchdb format. That would potentially provide a "one database" solution that also doesn't conflict with the sync problem I mentioned in my previous email.
Andreas _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
