On Jun 21, 2013, at 14:16 , Adam Kocoloski <[email protected]> wrote:
> On Jun 21, 2013, at 7:58 AM, Jan Lehnardt <[email protected]> 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. I didn’t make this very clear, maybe I have a simplified concept of git remotes in my head. I don’t think git server / repos are a useful analogy, because most people start out at the repo level and then down. Remotes are just locations for a repo (you know this). What I did not have in mind is a semantic analogy as you describe (which is totally valid!), I was coming from my usage of git remote: git remote add remote-name url git fetch remote-name After which remote-name/branches are available to me. My correlation of databases and branches is purely on the ”what is on the top level of a remote”. A CouchDB remote could be another CouchDB server and a fictional `couch remote add remote-name url` would make `remote-name` available for further operations, e.g. `couch replicate db-name remote/db-name` (read git push <localbranch> <remote-branch> note that git lists the remote first in reality, but I want to express a from-to relationship so I can also say: `couch replicate remote/db-name db-name` to pull changes from the remote db). `couch list remote-name` would give me list of databases available on the target server etc. Alternatively a CouchDB remote could be the location of a database anywhere identified with an URL. (the concept of remotes as proxies for branches took a while for me to grok when learning git, so maybe we can simplify this in the context of CouchDB: couch remote add remote-db-name url couch replicate local-db-name remote-db-name Or the reverse: couch replicate remote-db-name local-db-name Listing databases on another server would be out of band for this model. But maybe that is confusing and your approach is better because it also has a semantic mapping of operations further down, but I hope this shows where my thinking came from. All I really wanted here is see if we could make things simpler for our users and that there is some work to be done :) Best Jan --
