I'll second Jason Smith. Having a simple, clear way to insure that a replication has caught up is important, and async polling isn't going to be performant enough for some applications.
That said, having that way be something related to the _replicator db would be fine. I'm not attached to the current spelling. Eli On Mon, Sep 23, 2013 at 3:56 AM, Jason Smith <[email protected]>wrote: > For my money I rather like the sync and the async API. It could be > more orthogonal but it's not so bad. If I only have a few doc ids to > replicate, I prefer the sync way (_replicate) rather than creating a > document and watching it by polling or _changes or something. > > On Mon, Sep 23, 2013 at 5:44 PM, Dave Cottlehuber <[email protected]> > wrote: > > On 23. September 2013 at 11:33:55, Steven Barlow ([email protected]) > wrote: > > > > cc'ing dev@ on this. > > > >>If _replicate was depreciated, there would be no way to schedule your > >>own replications. Amongst other things, the _replicator database is > >>inconvenient when a client machine uses different proxies on different > >>connections. > > > > Good point. Benoît, I don't think thats the intent? > > > >>> (note: we should really deprecate _replicate). > >> > > > > I think we should deprecate the endpoint but fold the functionality into > _replicator. Or the other way round :-). THERE CAN BE ONLY ONE > replicat(e|or). > > > > A+ > > Dave Cottlehuber > > > > > > >
