Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 51837 invoked from network); 24 Jun 2009 07:45:13 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 24 Jun 2009 07:45:13 -0000 Received: (qmail 23328 invoked by uid 500); 24 Jun 2009 07:45:23 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 23258 invoked by uid 500); 24 Jun 2009 07:45:23 -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 23248 invoked by uid 99); 24 Jun 2009 07:45:23 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 24 Jun 2009 07:45:23 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of b.candler@pobox.com designates 208.72.237.25 as permitted sender) Received: from [208.72.237.25] (HELO sasl.smtp.pobox.com) (208.72.237.25) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 24 Jun 2009 07:45:13 +0000 Received: from localhost.localdomain (unknown [127.0.0.1]) by a-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTP id C65E522EB7; Wed, 24 Jun 2009 03:44:48 -0400 (EDT) Received: from mappit (unknown [80.45.95.114]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTPSA id 64F4122EB6; Wed, 24 Jun 2009 03:44:47 -0400 (EDT) Received: from brian by mappit with local (Exim 4.69) (envelope-from ) id 1MJN9x-0003up-TX; Wed, 24 Jun 2009 08:44:45 +0100 Date: Wed, 24 Jun 2009 08:44:45 +0100 From: Brian Candler To: Noah Slater Cc: dev@couchdb.apache.org Subject: Re: Unicode normalization (was Re: The 1.0 Thread) Message-ID: <20090624074445.GA14603@uk.tiscali.com> References: <20090623164652.GB12685@tumbolia.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090623164652.GB12685@tumbolia.org> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Pobox-Relay-ID: E4CFE6A0-6092-11DE-947E-DC021A496417-28021239!a-sasl-quonix.pobox.com X-Virus-Checked: Checked by ClamAV on apache.org On Tue, Jun 23, 2009 at 05:46:52PM +0100, Noah Slater wrote: > On Tue, Jun 23, 2009 at 09:26:23AM +0100, Brian Candler wrote: > > As an aside: I support that subtly different encodings of the "same" > > document (according to NFC) should have different revs, because (a) it's > > unlikely that multiple different client implementations will be making the > > same changes to the same documents (i.e. the clients in a cluster are likely > > to be homogeneous), and (b) such conflicts are easy to resolve anyway. > > Clients on the Web are anything but homogeneous! True. I was thinking more of the three-tier architecture, where the middle layer is scaled horizontally, and consists of identical nodes. For the two-tier "Couchapp" type application, where each client is a completely independent user, it seems less likely to me that two different users would make exactly the same overlapping edit to the same document. Not impossible of course. Maybe some Couchapps will have extensive conflict-resolution algorithms written in Javascript and running inside browsers. I'd hate to have to do that myself :-) The idea of fully-trusted clients, with all business logic running in the client, scares me. You may as well just give raw SQL connections to anyone who wants them. I've seen client apps written that way too of course :-)