On Jun 21, 2013, at 10:07 AM, Jan Lehnardt <j...@apache.org> wrote: > > 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” :)
No offense taken :) There's definitely value in making this sort of analogy with developers; let's keep at it and I'm sure we'll converge on a standard way of expressing it. Adam
