couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: Fauxton Tidings
Date Fri, 21 Jun 2013 14:07:06 GMT

On Jun 21, 2013, at 15:35 , Jan Lehnardt <> wrote:

> On Jun 21, 2013, at 14:16 , Adam Kocoloski <> wrote:
>> On Jun 21, 2013, at 7:58 AM, Jan Lehnardt <> 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
> --

View raw message