On Tue, Aug 11, 2009 at 11:40 AM, Damien Katz<[email protected]> wrote: > > 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 think this is a great idea. The Futon interface for configuring this will probably take a lot of the mystery out of replication for our users. Bonus that using a config db suddenly makes our replicator trivial to configure across a cluster with tools like Chef. > 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 > > -- Chris Anderson http://jchrisa.net http://couch.io
