couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <kocol...@apache.org>
Subject Re: Fauxton Tidings
Date Fri, 21 Jun 2013 14:17:33 GMT
On Jun 21, 2013, at 10:07 AM, Jan Lehnardt <jan@apache.org> wrote:

> 
> On Jun 21, 2013, at 15:35 , Jan Lehnardt <jan@apache.org> wrote:
> 
>> 
>> On Jun 21, 2013, at 14:16 , Adam Kocoloski <kocolosk@apache.org> wrote:
>> 
>>> On Jun 21, 2013, at 7:58 AM, Jan Lehnardt <jan@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
Mime
View raw message