Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 240B7FA6B for ; Wed, 24 Apr 2013 14:12:21 +0000 (UTC) Received: (qmail 19918 invoked by uid 500); 24 Apr 2013 14:12:19 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 19773 invoked by uid 500); 24 Apr 2013 14:12:19 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 19753 invoked by uid 99); 24 Apr 2013 14:12:19 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 24 Apr 2013 14:12:19 +0000 X-ASF-Spam-Status: No, hits=-0.5 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of stemail23@gmail.com designates 209.85.220.51 as permitted sender) Received: from [209.85.220.51] (HELO mail-pa0-f51.google.com) (209.85.220.51) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 24 Apr 2013 14:12:12 +0000 Received: by mail-pa0-f51.google.com with SMTP id jh10so1217987pab.10 for ; Wed, 24 Apr 2013 07:11:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:from:in-reply-to:mime-version:date:message-id :subject:to:content-type; bh=ELPjc7PgvjcGv1ZY74blYkIV5gaxBONrBBxTgfNGZkE=; b=0t4lT1FJllH9wkek0kwVOX+Y1lvEnd81VUiCMjAv4gidpFotB9YuWYp2n6vhLwjMQ8 rw5GgZpd6HGQVra9pwI4WfjwVtl/jsqCBfBbzNyHBdx4KlvYgdOdeeEusQbvkeKibcCv UoIUpAAs9VCkAP5psr0T4z4DWry1qhYTRgXh7iFEIlQCEZuNcFM2MuYFktmIqprYnL0h W7IvORYPQpeTwvZtAGFotqbvvBLOIKxdZaJOkt4Yg/CVBSQik4Gv1Xm1OcV855KKNbPw Wa30BPM9glo7Whmu4gJc5XVFLKk/4BjS1uuiQyit/5Uj5dz0ZJdLyu300IuwVMRkjR3G +JOQ== X-Received: by 10.68.112.196 with SMTP id is4mr48344692pbb.117.1366812711976; Wed, 24 Apr 2013 07:11:51 -0700 (PDT) References: From: Steven Barlow In-Reply-To: Mime-Version: 1.0 (1.0) Date: Thu, 25 Apr 2013 00:11:50 +1000 Message-ID: <-5746397928987888191@unknownmsgid> Subject: Re: _replicator database and proxies To: "user@couchdb.apache.org" Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org Thanks for the comments. I appreciate that each replication document is independent. I guess I'm questioning whether the proxy configuration is typically an attribute of the individual replication entity, rather than being a "system-wide" connection configuration. I'm struggling to envisage a scenario whereby different replication documents might have different proxy settings? To support that use case though, I guess, why not retain a replication document level setting as an override, but introduce a global setting for what, at least in my opinion, is the more typical use case? In answer to the question, "why is my configuration changing so rapidly?" - My proxy settings change several times every day when my laptop travels to and from my home network (no proxy), to my office network (which requires a proxy for Internet access). On 24/04/2013, at 11:42 PM, Robert Newson wrote: > Q: "Why is the proxy configuration part of the replication document at all? > > A: Because each replication document is an independent entity. > > Making it global works for your case but not the general case. Why is > your proxy configuration changing so rapidly? > > B. > > On 24 April 2013 08:31, Steven wrote: >> OK, please excuse the bump, but really? No takers on this one? >> >> I'm surprised if I'm the only person encountering this situation. Is nobody >> else working on a system with replication to laptop devices that use >> multiple connections? >> >> Here's my biggest confusion: Why is the proxy configuration part of the >> replication document at all? Surely a global proxy setting would make way >> more sense, otherwise, the only way I can see around this issue is to tear >> down the entire replication database document set, and rebuild it when I >> detect a change in proxy configuration. That seems like madness! >> >> Any comments appreciated. >> >> Cheers. >> >> >> On Fri, Apr 12, 2013 at 1:14 PM, Steven wrote: >> >>> Question about using the _replicator database to set up persistent >>> replications from a machine that uses various different connections, >>> sometimes behind a proxy, other times not. >>> >>> Question is: Given that the proxy server information is part of the >>> replication document, the replication breaks (returns an error) when the >>> connection changes to use a different, or no, proxy. How am I supposed to >>> handle this situation? >>> >>> Also, an observation: when the replication document contains "proxy": null >>> (in V1.3), the replication fails, this caught me out for a while, the >>> replication document proxy parameter must be entirely absent to specify no >>> proxy. >>>