On Aug 10, 2009, at 4:09 PM, Adam Kocoloski wrote:
Hi folks, I committed some code today to enable continuous
replication between CouchDB servers. I could use some help defining
the client API, though. To recap, replication has always been
triggered RPC-style by a request like
Yeehaw!!!
POST /_replicate -d '{"source":"foo", "target":"http://example.com/
bar"}'
this request would block until the replication had completed and
then you'd get a 200 response code and something like
{
"ok": true,
"session_id": uuid(),
"source_last_seq": 1234,
"history":[....]
}
Well, it doesn't make too much sense to do the same with continuous
replication because the response will never arrive. Basically, I
think we need to answer the following questions:
1. How does a user trigger a continuous replication? Simplest
extension of the current API would be
POST /_replicate -d '{"source":"foo", "target":"http://example.com/
bar", "continuous":true}'
2. How does the server respond to that request? Perhaps a "202
Accepted" along with the replication ID?
3. How does a client monitor the progress of a continuous
replication? The replication will show up in _active_tasks, but I'd
like to have a way to get all the history information. If we return
the replication ID the client could GET the _local doc with that ID,
but we probably want a resource that's a bit easier to discover.
Maybe a special HTTP call to get replication info?
4. How can we configure replications that survive a server restart?
I think I'd like to see a replication config database, and a constant
replicator config process that reads the config info at server start
and starts the continuous replications. It monitors the config db for
changes and as new settings are written spawns, restarts or shuts down
replication tasks.
I can't think of a use case where it's okay to have it *not* survive a
restart. Continuous replications aren't something you do temporarily,
I think.
-Damien
Adam
