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).
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. 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. B. On 19 January 2012 21:45, Benoit Chesneau <bchesn...@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 propose to keep only one entry point : _replicate and pass the > parameter we want to it. What do you think ? > > - benoit
