On Jun 21, 2013, at 15:35 , Jan Lehnardt <j...@apache.org> wrote: > > On Jun 21, 2013, at 14:16 , Adam Kocoloski <kocol...@apache.org> wrote: > >> 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. > > 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,
sorry, this may sound a bit rude, what I mean is “I don’t understand yet how it would be a useful analogy, give me some time to think about it” :) > 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 > -- > > > > > > >
