Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 46271 invoked from network); 10 Jan 2010 18:25:10 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 10 Jan 2010 18:25:10 -0000 Received: (qmail 20767 invoked by uid 500); 10 Jan 2010 18:25:09 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 20696 invoked by uid 500); 10 Jan 2010 18:25:09 -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 20686 invoked by uid 99); 10 Jan 2010 18:25:09 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 10 Jan 2010 18:25:09 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of ccinnebar@gmail.com designates 209.85.216.180 as permitted sender) Received: from [209.85.216.180] (HELO mail-px0-f180.google.com) (209.85.216.180) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 10 Jan 2010 18:25:01 +0000 Received: by pxi10 with SMTP id 10so15351499pxi.13 for ; Sun, 10 Jan 2010 10:24:39 -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=zLG+CqX8FtrsrGv2LBs5cvqZWIDDvMeTWJu2SzcZBb0=; b=jXShkEPmkVUHwzs/59bX1Cix5wVdrJudZ8wpyIF174fV+7hFFqQoZATL7373e5qS7V QyutocP2i93oDPRMzkTn0ZYEoQOL4AUMIREpHlbABgQmOkOT5Y3ZKeQyirM9E3G323WH M8t9PifCjUclkvtpzfh1uqrsqAIz4Irsiqro8= 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=OgZBTwhSC23wV20hCF6sLb0ouE3m0WqxxW9tlinKLI3r5mDLyRhqdjAk+F/iQhDU5O IUHhDJVlAupGGVNTMOk7wyaJMki8m6w9OKUX2PDQIu638Uaa7GctogQEy1pn/W9BNN30 DOFNJKUCyiTXFGDF/30A5ARRDb+pIA9FUOW0k= MIME-Version: 1.0 Received: by 10.114.251.10 with SMTP id y10mr2672651wah.149.1263147879855; Sun, 10 Jan 2010 10:24:39 -0800 (PST) In-Reply-To: <1bca98391001100852re326455x69e8e8876d428864@mail.gmail.com> References: <20100109221734.GA32664@uk.tiscali.com> <1bca98391001100852re326455x69e8e8876d428864@mail.gmail.com> Date: Mon, 11 Jan 2010 05:24:39 +1100 Message-ID: <87f645c81001101024u3d3df91cv3b8cd2749f2375b3@mail.gmail.com> Subject: Re: Initial couchdb accounts feedback From: cinnebar To: user@couchdb.apache.org Content-Type: multipart/alternative; boundary=0016367f926bad76c6047cd388ee X-Virus-Checked: Checked by ClamAV on apache.org --0016367f926bad76c6047cd388ee Content-Type: text/plain; charset=ISO-8859-1 technically it is the user db rather than the users db. > _usr or _user would seem to make sense to me, since the _ is reserved namespace in couchdb (e.g. _id and _rev). > Yeah, "magic" fields should have a leading underscore to show they are > in the reserved namespace, but let's not drop the 'e' in user, it's > not the 60's anymore, we don't need to sacrifice readability to gain > an extra byte. i follow the logic of the pattern of underscoring feilds such as _id and _rev but i dont think it follows that then the user db name should also be underscored. if anything to maintain the pattern "roles" should be underscored if its a reserved namespace field but i dont think this would be necessarily justified. what name is given to the user db appears to be more a question of common practice and dogma in systems architecture rather than a sacrifice of readibility. id and rev dont appear to sacrifice readibility. convention based on dogma is drag whichever era or social band spawned it. succinct is better for eg _id and _rev are readable but they are missing loads of letters. > 'usr' is typically from UNIX filesystem hierarchy, which is a horrendous mess... this relates more to the unix architecture than the particular use of 'usr' methinks. > I quite like using full english names where that doesn't mean wasting too much space. i agree but things like the name of the user db are structural underpinnings rather than simple data so applying a naming convention to distinguish the set actually improves readability and resolves other issues, in my experience. we will be using 'usr' to name the user db no matter what, for a number of reasons that may be unique to our doc/system architecture at present, the only issue we have is that changing the hardcoded default a) would be an irritating manual correction on each realease or b) a patch to allow overriding the default may compromise security to some degree. the only reason i am posting on this thread is because the changes significantly affect our use of couchdb. more time is needed to look into the issues here but chris seems to be moving fast so... --0016367f926bad76c6047cd388ee--