couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <>
Subject Re: continuous replication API discussion
Date Tue, 11 Aug 2009 18:40:06 GMT

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


> POST /_replicate -d '{"source":"foo", "target":" 
> 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":" 
> 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.


> Adam

View raw message