On Thu, Jan 19, 2012 at 1:52 PM, Robert Newson <rnew...@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. > Even if it needs another thread, can you elaborate on that? I had started some work for http://markmail.org/message/hogagl2qbhfgxmf7 and I'm curious to know the problems you see in. > Bottom line: It's my opinion that _replicator (and _user) were wrongly > exposed as full-blooded databases when all we needed to use was the > database format (and carefully curate API endpoints). But, alas, that > train has sailed. > Imo such dbs should be hidden, and we could only provide entry points accessing to them. For example having all systems dbs under /couchdb/ prefix and hide them for others excepts admins. Just like postgres does. I'm agree it was a mistake to expose them. I think we should stop to do it in near future imo. - benoit
