From dev-return-2885-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Tue Feb 24 13:13:41 2009 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 2590 invoked from network); 24 Feb 2009 13:13:41 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 24 Feb 2009 13:13:41 -0000 Received: (qmail 19415 invoked by uid 500); 24 Feb 2009 13:13:41 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 19063 invoked by uid 500); 24 Feb 2009 13:13:40 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 19052 invoked by uid 99); 24 Feb 2009 13:13:40 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Feb 2009 05:13:40 -0800 X-ASF-Spam-Status: No, hits=3.4 required=10.0 tests=FS_REPLICA,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of patrick.antivackis@gmail.com designates 209.85.220.165 as permitted sender) Received: from [209.85.220.165] (HELO mail-fx0-f165.google.com) (209.85.220.165) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Feb 2009 13:13:34 +0000 Received: by fxm9 with SMTP id 9so4704952fxm.11 for ; Tue, 24 Feb 2009 05:13:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=+wnsee9jNi4gyOtZeS5bc7TKrM3TKzcgWmnsXO3Ks2w=; b=jeV7AwlPKKXerVYvipzUSH/FQ0f2KaUKPLUW8FTbJyaLqtb8eVrdlN06oRfv66HX4f /wq1I9EOGC33L+/AIHZq7tszccQVPpfyM8zaxIKApxpfoXU73i8m95n0CXH+lPrYxfqV jQa3U3I1a9buEAX4P39gB02ZiC47boDgLSfuU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=AhggdtKJ3wignktHFCWRK/++Y/Lqsb0e7ETUkB4WuVV84rX0aGlYHBqi/V97mxiAeL wb/RuEj/1OnCZI0q/6tXt7cIPwwaq5O6AG5mRoEVuYskqSxdBzg094g5F9enjmT4Y99v KHN4eYEvLJO/uPqdfG02MGuqULY73vrYRREWw= MIME-Version: 1.0 Received: by 10.223.127.8 with SMTP id e8mr7150745fas.81.1235481192394; Tue, 24 Feb 2009 05:13:12 -0800 (PST) In-Reply-To: <7B3B919D-E34A-4DFB-8479-C221CD311257@apache.org> References: <64a10fff0902231502n317456f8l80a9d19c36b704aa@mail.gmail.com> <3C3204C0-0662-4012-B62B-9FA8643F4BC8@gmail.com> <7060483c0902240006r74ba460ctfad095717fecd270@mail.gmail.com> <7060483c0902240452y7102229ai8c310b6720d21728@mail.gmail.com> <7B3B919D-E34A-4DFB-8479-C221CD311257@apache.org> Date: Tue, 24 Feb 2009 14:13:12 +0100 Message-ID: <7060483c0902240513l5d37c7cdq741711d0018898c0@mail.gmail.com> Subject: Re: Fail on a simple case on replication From: Patrick Antivackis To: dev@couchdb.apache.org Content-Type: multipart/alternative; boundary=001636c5b6da9971430463a9e17f X-Virus-Checked: Checked by ClamAV on apache.org --001636c5b6da9971430463a9e17f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 2009/2/24 Jan Lehnardt > > On 24 Feb 2009, at 13:52, Patrick Antivackis wrote: > >> It's like all politically correct terminology where you use a stupid >>>> expression in order to be as neutral as possible. >>>> >>>> >>> You have a point here, it is about avoiding conflict. But I don't think >>> we're looking for a neutral term here, but one with a better name. >>> I'd go with _access_token if it weren't too long. _rev is nice and short >>> and _token might as well be _wibble. API design is hard. >>> >>> >> May be it's about conflict, but as it's also a previous release, it's by >> definition a revision. The fact that the revision is no more there is not >> changing the fact that it's a revision. >> > > Haha, language ambiguity for the win :) I meant conflict between > users applying prior understanding of the term "revision" to CouchDB > revisions causing a conflict. I did not mean using _rev as a token to > manage write conflicts for a document. I need to be more careful with > these words :) > Don't worry i'm neither english speaking native too. > > > > That's why if the name is changed, the functionality to access a previous >> revision should be removed. >> > > I could see that being a valid conclusion and I think that would be > covered with disabling the feature by default and make it an opt-in > like Damien suggested. We also could just nuke it completely and > wait for complaints before reconsidering making it an opt-in. > > Great so my vote becomes : -0 > > > Cheers > Jan > -- > > > -- >>> >>> >>> >>> >>> IMO if you change this >>> >>>> attribute name it's even better to remove all possibilities to a access >>>> a >>>> previous rev if still there, and change it's value by a timestamp >>>> >>>> >>>> Regards >>>> >>>> 2009/2/24 Antony Blakey >>>> >>>> >>>> On 24/02/2009, at 12:51 PM, Antony Blakey wrote: >>>>> >>>>> The project founder and the PMC, are all committed to that replication >>>>> >>>>> model, which is derived from Notes. >>>>>> >>>>>> >>>>>> BTW I'm the only one in the community that has expressed any strong >>>>> desire >>>>> to change this - I'm not implying any community division, just pointing >>>>> out >>>>> that it's both an historical artifact, and accepted by the major >>>>> contributors and committers. >>>>> >>>>> Antony Blakey >>>>> -------------------------- >>>>> CTO, Linkuistics Pty Ltd >>>>> Ph: 0438 840 787 >>>>> >>>>> Plurality is not to be assumed without necessity >>>>> -- William of Ockham (ca. 1285-1349) >>>>> >>>>> >>>>> >>>>> >>>>> >>> > --001636c5b6da9971430463a9e17f--