couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Keen <ben.k...@gmail.com>
Subject Re: _replicate vs. _replicator
Date Sat, 18 Jun 2016 08:27:56 GMT
Hey Joan, thanks for the response! I ended up having a little
back-and-forth with Bob Newson over slack and got it figured out.

But yes, it's not quite as clear cut as I hoped it would be.

Ben

On Fri, Jun 17, 2016 at 8:38 PM, Joan Touzet <wohali@apache.org> wrote:

> Hi Ben, did anyone ever get back to you on this? I know that the
> core developers have a LOT of reservations about the _replicator database,
> primarily the fact that the backing store for a _replicator endpoint
> probably shouldn't be a database itself (though it could conceivably
> present
> a similar API to one).
>
> Personally I still use the _replicate endpoint most of the time.
>
> -Joan
>
> ----- Original Message -----
> From: "Ben Keen" <ben.keen@gmail.com>
> To: dev@couchdb.apache.org
> Sent: Friday, June 3, 2016 10:11:30 AM
> Subject: _replicate vs. _replicator
>
> Hey!
>
> Wonder if I could get some advice here. I’ve been working on refactoring
> the replication feature in Fauxton to POST to the /_replicator database
> rather than using /_replicate.
>
> Having all replications (continuous/one-offs) logged in one place (the
> _replicator database) leaves a nice paper trail of replication history.
> [N.B. I’ve been speaking to Markus Fischboeck, who’s doing work on adding
> some advanced replication features - we’re working in parallel].
>
> I’ve been able to get replications working, but it requires passing both
> basic headers in the POSTed JSON content, and the creds in the actual
> endpoint URL, like so:
>
> http://bob:bobspassword@mylocalsite.dev:8000/_replicator
>
> It’s the latter that particularly worries me. I don’t believe this is
> secure over http (correct?), and since Fauxton could be run anywhere, I
>  wanted to know if I should stop heading down this road and stick with
> _replicate.
>
> Thanks!
>
> Ben
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message