couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eli Stevens (Gmail)" <wickedg...@gmail.com>
Subject Re: HTTP POST to _replicate is sync?
Date Tue, 24 Sep 2013 03:33:31 GMT
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 <jason.h.smith@gmail.com>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 <dch@jsonified.com>
> wrote:
> > On 23. September 2013 at 11:33:55, Steven Barlow (stemail23@gmail.com)
> 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
> >
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message