Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of paul.joseph.davis@gmail.com
 designates 209.85.220.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CABvT1DFmzuR9ZFZmEETe1fkxryy4QC3Z32O31+_rpkbbP0rBFQ@mail.gmail.com>
References: 
 <CAJNb-9rRFptd93XPDD8Uu1E5YFy-vrUyCPL_ZiXNGjWJTkvFEA@mail.gmail.com>
 <CABvT1DFmzuR9ZFZmEETe1fkxryy4QC3Z32O31+_rpkbbP0rBFQ@mail.gmail.com>
From: Paul Davis <paul.joseph.davis@gmail.com>
Date: Thu, 19 Jan 2012 15:56:59 -0600
Message-ID: 
 <CAJ_m3YArF9tJt41FjYGS35+Wj_q8_yyUq9mLKf0+P3+RtykC1g@mail.gmail.com>
Subject: Re: Do we need 2 entry points for the replication?
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 19, 2012 at 3:52 PM, Robert Newson <rnewson@apache.org> wrote:
> I would prefer to see a single /_replicate entrypoint, with, say,
> "persistent":true to indicate that the replication settings should be
> stored. We would also need an API to list all persistent replication
> tasks and one to delete them. Which would look a lot like the
> _replicator database, though much more controlled (no public passwords
> for those jobs that require auth).
>

+1

> I think it's too late, though. There's work on master to fix the
> issues with _replicator now (and the similar ones in _user). While I
> don't like the approach, it does solve the problem.
>

We can break it eventually and I think we should consider it sooner
rather than later.

> Bottom line: It's my opinion that _replicator (and _user) were wrongly
> exposed as full-blooded databases when all =A0we needed to use was the
> database format (and carefully curate API endpoints). But, alas, that
> train has sailed.
>

I seem to recall someone else with a similar opinion even when these
things were being designed. ;)

Also, what kind of crazy sailing trains do you brits have over there
and how do I get a ticket to ride on one?

> B.
>
> On 19 January 2012 21:45, Benoit Chesneau <bchesneau@gmail.com> wrote:
>> Think it's time to relaunch this threads following the 2 separate
>> discussions that we had this morning. Actually we have 2 ways to
>> handle the replication:
>>
>> - `_replicate` : which isn't persistent and where you can follow the
>> task in active tasks
>> - `_replicator`: wich is a plain db where any replication task is
>> persistent. In that case even if a replication task is finished, a
>> document stay in the replicator db and you will have to delete it and
>> compact the db from time to time.
>>
>> Both are their use cases, and while i think it's good to keep the
>> different approaches (persisten against fire and forget), I think the
>> API should be more consistent by offering only 1 end point for the
>> replication. We could then having different parameters depending on
>> the replication type we want (persistent or fire and forget). Also
>> both should appear in the active tasks (maybe this point have been
>> solved since).
>>
>> So I =A0propose to keep only one entry point : _replicate and pass the
>> parameter we want to it. What do you think ?
>>
>> - benoit