Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 15722 invoked from network); 30 Oct 2009 03:02:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 30 Oct 2009 03:02:26 -0000 Received: (qmail 25983 invoked by uid 500); 30 Oct 2009 03:02:25 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 25812 invoked by uid 500); 30 Oct 2009 03:02:25 -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 25802 invoked by uid 99); 30 Oct 2009 03:02:24 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 30 Oct 2009 03:02:24 +0000 X-ASF-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of paul.joseph.davis@gmail.com designates 209.85.211.186 as permitted sender) Received: from [209.85.211.186] (HELO mail-yw0-f186.google.com) (209.85.211.186) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 30 Oct 2009 03:02:22 +0000 Received: by ywh16 with SMTP id 16so2492532ywh.13 for ; Thu, 29 Oct 2009 20:02:01 -0700 (PDT) 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 :from:date:message-id:subject:to:content-type; bh=6cPRHc+1GNead0MxFfn5EYHfvhK1JfK73RjfzrhSziE=; b=YUA3L1xS8Z/mlR7Lv7ZU16dLn7yHxU7blpc4TE/rtnQkyvZERdh1z2kqKYzBWrBl5k UuxrKpR4RQpBzUleS+/dG9mDJcaNWizVgniAJ1xvra7iJ9ROKwvSvDfA3s/bBMDwvbet 4iyxkAuLXKr5vIcpdNCrjkyx/+VZGxiyIMGoA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=pcC+Y59p9Go+rPM7ujpvNkQPRpZ1ev3E532wUTtGb9UwVjPvWQ+rE5CDJQMmka4q6Z 8gFi4sxMyOCfSww5A3ZYuIM+4Ada1ab24D6uK3eeSwmxZHiHJYWLAV5+V0vJQZ3kG8Ss Np3xP6MFKh0WRZWd33p+UbtdE5lTqGdElUW7A= MIME-Version: 1.0 Received: by 10.101.106.33 with SMTP id i33mr1288512anm.20.1256871721151; Thu, 29 Oct 2009 20:02:01 -0700 (PDT) In-Reply-To: <3f1568830910291619g3c1afdadn1aaeb766a43745f3@mail.gmail.com> References: <3f1568830910291547ldc358e3s30bf07c6c9ad954c@mail.gmail.com> <3f1568830910291619g3c1afdadn1aaeb766a43745f3@mail.gmail.com> From: Paul Davis Date: Thu, 29 Oct 2009 23:01:41 -0400 Message-ID: Subject: Re: Proposal regarding reserved names To: user@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 29, 2009 at 7:19 PM, Julian Goacher wrote: > Hi Paul, > > I think this is a slightly different use case though. The framework sits as > a layer between the user and the db; I don't want the user to wrap their > data to use the framework. Rather, I want to annotate a user generated > document with additional data - which is essentially what the existing > underscored names currently do. If you have a layer between the user and the db then I don't see what would be cleaner than using a nested object. Otherwise your user has to face the fact that none of their top level members are able to be underscore prefixed. There might be implications for M/R I guess, but that'd depend on how much framework there is. Bottom line, I'm not sure how much its gonna be worth it to special case _meta as a not reserved member. I'd need to be a bit more convinced before I'd say that punching a hole in the underscore prefix rule would be ok. As it is, you could just as well do $meta or something else without a difference. Paul Davis