On Jun 21, 2013, at 7:58 AM, Jan Lehnardt <j...@apache.org> wrote: >> Step two is build out a proper interface around the _replicator >> database, allowing you to create new persistent replications, >> introspect existing replications, look at historic replications, and >> also to visually expose the powerful advanced options of the new >> replicator allowing higher throughput replications. >> >> What kinds of interfaces sounds useful for interacting with the >> replicator database? What would you find useful for creating and >> managing replications through Fauxton? > > While a bit oblique in implementation, I like the git “remote” concept > and I think it makes sense in the CouchDB context. Whether a remote > is another CouchDB installation and databases are “branches” (in git lingo) > or whether a database is a remote is up to decision, but I’d like > to be able to configure a set of remotes for my current server (manually > and automatically) and then start/stop/schedule/observe replication > between the local couch and a “remote”, or two “remotes”, or whatever > else makes sense.
Co-opting the git parlance could work well. For my money the right analogy is that a CouchDB server is a remote and databases take the place of repos. Branching happens at the granularity of a document, not a database, and replication pushes all branches of all documents in the database to the remote. Adam
