On May 19, 2010, at 2:17 PM, Randall Leeds wrote: > On Wed, May 19, 2010 at 13:06, Filipe David Manana <fdman...@gmail.com> wrote: >> Answers bellow >> >> On Wed, May 19, 2010 at 8:35 PM, Adam Kocoloski <kocol...@apache.org> wrote: >>>> >>>> 3) Is the checkpoint ID generation algorithm backwards-compatible? Or >>> will users who upgrade restart all replications from scratch? >>> >> >> Well, the checkpoint IDs will be "_local/" + repDocId. So, they are >> basically user generated. Checkpoints will still remain in the source and >> target DBs (I don't write them to the _replicator DB). > > So if I create a _replicator doc with an ID corresponding to an > old-style replication ID it'll use the same checkpoints? > > I can't remember, is it possible to change the doc_id with an _update > handler? I haven't looked at your code yet to see what paths it takes, > but if it's an erlang handler in the .ini I'm sure we could hack this. > Basically, I'm thinking to make _replicator a lot like the _replicate > from an API standpoint. Disable PUT but have POST to _replicator > create the doc with the rep id as we used to calculate it. > > In fact, why name it _replicator at all??? We already have a POST to > _replicate that returns the id. This API looks a lot like the document > API, we just create a gen_server instead of a document. But if we're > careful couldn't we transparently turn the _replicate endpoint into > the _replicator DB under the hood and users don't even have to know > the difference (unless they need/want to)? > > -Randall
[retry after a delivery failure from gmail. maybe something is up with Apache servers?] The main goals as I see them are: 1) replications continue even when the server restarts 2) it is easy to write replication manager couchapps I think having the standard database API for these documents (even if it is admin only) will be a good way to allow people to use the existing toolkit to query and create replications. Of course it'd be nice to be backwards compatible with the existing replication API. Chris
