Return-Path: 
 <dev-return-29224-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org>
X-Original-To: apmail-couchdb-dev-archive@www.apache.org
Delivered-To: apmail-couchdb-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 81F7F103F6
	for <apmail-couchdb-dev-archive@www.apache.org>;
 Tue, 24 Sep 2013 03:34:17 +0000 (UTC)
Received: (qmail 70864 invoked by uid 500); 24 Sep 2013 03:34:08 -0000
Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org
Received: (qmail 69943 invoked by uid 500); 24 Sep 2013 03:34:00 -0000
Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@couchdb.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@couchdb.apache.org>
List-Post: <mailto:dev@couchdb.apache.org>
List-Id: <dev.couchdb.apache.org>
Reply-To: dev@couchdb.apache.org
Delivered-To: mailing list dev@couchdb.apache.org
Received: (qmail 69919 invoked by uid 99); 24 Sep 2013 03:33:58 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Sep 2013 03:33:58 +0000
X-ASF-Spam-Status: No, hits=2.5 required=5.0
	tests=FREEMAIL_REPLY,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of wickedgrey@gmail.com
 designates 74.125.82.172 as permitted sender)
Received: from [74.125.82.172] (HELO mail-we0-f172.google.com) (74.125.82.172)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Sep 2013 03:33:53 +0000
Received: by mail-we0-f172.google.com with SMTP id w61so4029580wes.3
        for <multiple recipients>; Mon, 23 Sep 2013 20:33:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        bh=udzONX3SOKsQtyYuSWmrgR8oLpzuBysMNHiZJiNGnF8=;
        b=DNRzB0/JOqjDLr0bJCAbpUPGTkPqBGN5Q7JpJ3IhOuAUW8ESHtmmY+KFht4lTilhgf
         9xb6BWvMnEGpeSCEawmKRProshrVECpIVxN9kJCb8k0/263Z8PfHK/xgKMwTgrxXLq0i
         hObXF3XNkiH2ei9pVCN6bRB4+c4cSoToESBhL4UzfmGXYhLXrV8qxZUT7rD70P6emwHS
         JZp8yhuTyKjw7OG45iCsw2611hC11WTydDK8WsjLAnCh9dUzhDfwJKGplZVa+0TJWl/+
         PFIiylXtfT+Xw9wfQRN5qweiCOqOqO9YTXUmh2jlzb72+q/9hOZEIcLNF8+WY6Z+rcO8
         8iZw==
MIME-Version: 1.0
X-Received: by 10.180.198.44 with SMTP id iz12mr16212126wic.32.1379993611711;
 Mon, 23 Sep 2013 20:33:31 -0700 (PDT)
Received: by 10.180.11.3 with HTTP; Mon, 23 Sep 2013 20:33:31 -0700 (PDT)
In-Reply-To: 
 <CACLy94UzB6AHprrkuZ_91EBMFj=g51iOfTswBocaELFat6W26g@mail.gmail.com>
References: 
 <CAKvLi7PBEgVXfyQ+6dTp=NFfq2ZxWYk__BqefiogB7Dmpq8b+A@mail.gmail.com>
	<CAJNb-9o_NHL-BSsWm0rLPXj157EUE38t_Xsztc6KFqi3NNCd_Q@mail.gmail.com>
	<-1900369759779039435@unknownmsgid>
	<etPan.52401b8a.327b23c6.255@akai.jsonified.com>
	<CACLy94UzB6AHprrkuZ_91EBMFj=g51iOfTswBocaELFat6W26g@mail.gmail.com>
Date: Mon, 23 Sep 2013 20:33:31 -0700
Message-ID: 
 <CADa34LDLZn_5ktsVVuqqrr_hjb9uWO0EWpJkthWPgHpvASRd5g@mail.gmail.com>
Subject: Re: HTTP POST to _replicate is sync?
From: "Eli Stevens (Gmail)" <wickedgrey@gmail.com>
To: user <user@couchdb.apache.org>
Cc: CouchDB Developers <dev@couchdb.apache.org>
Content-Type: multipart/alternative; boundary=047d7b624dfe04baf804e718cdd5
X-Virus-Checked: Checked by ClamAV on apache.org

--047d7b624dfe04baf804e718cdd5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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=EEt, I don't think thats the intent?
> >
> >>> (note: we should really deprecate _replicate).
> >>
> >
> > I think we should deprecate the endpoint but fold the functionality int=
o
> _replicator. Or the other way round :-). THERE CAN BE ONLY ONE
> replicat(e|or).
> >
> > A+
> > Dave Cottlehuber
> >
> >
> >
>

--047d7b624dfe04baf804e718cdd5--