From dev-return-3103-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Wed Mar 04 16:17:05 2009 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 15048 invoked from network); 4 Mar 2009 16:17:05 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Mar 2009 16:17:05 -0000 Received: (qmail 17541 invoked by uid 500); 4 Mar 2009 16:17:04 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 17517 invoked by uid 500); 4 Mar 2009 16:17:04 -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 17506 invoked by uid 99); 4 Mar 2009 16:17:04 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Mar 2009 08:17:04 -0800 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [83.97.50.139] (HELO jan.prima.de) (83.97.50.139) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Mar 2009 16:16:55 +0000 Received: from [192.168.1.100] (f053002027.adsl.alicedsl.de [::ffff:78.53.2.27]) (AUTH: LOGIN jan, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by jan.prima.de with esmtp; Wed, 04 Mar 2009 16:16:34 +0000 Message-Id: From: Jan Lehnardt To: dev@couchdb.apache.org In-Reply-To: <329362532.1236140156091.JavaMail.jira@brutus> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [jira] Created: (COUCHDB-280) relative links between resources provided by design docs Date: Wed, 4 Mar 2009 17:16:02 +0100 References: <329362532.1236140156091.JavaMail.jira@brutus> X-Mailer: Apple Mail (2.930.3) X-Virus-Checked: Checked by ClamAV on apache.org On 4 Mar 2009, at 05:15, Chris Anderson (JIRA) wrote: > Points of discussion: > > If we want to change the names of any of: _view, _show, _list, or > _design now is a good time to do it. We've been over the names _list > and _show many times, and while they aren't perfect, they are short, > and more-or-less descriptive of what they do. I'd still love to see _render/ used for both docs and views. /db/_design/foo/_render/renderfun/docid /db/_design/foo/_render/renderfun/viewname The problem with this of course is that the docid namespace gets polluted with viewnames (or vice versa) and 404-handling will prove to be tricky. _-prefixing viewnames would be one option, but then you can't have views named "design", heh :) /db/_design/foo/_render/renderfun/docid /db/_design/foo/_render/renderfun/_viewname Another possibility would be requiring prefixes for render functions: /db/_design/foo/_render/doc-renderfun/docid /db/_design/foo/_render/view-renderfun/viewname not neat, but better than _list and _show. The new URL layout might enable other solutions that I don't see yet. > The code is robust about changes to the _design db handler's name. > That is, we could continue to call them design docs, and store them > with ids like "_design/name", while changing the resource root so > that the above set of URLs could be something like (modulo an > attachments handler, "_files" here, for clarity): > > /db/_baz/foo/_view/bar?limit=10 > /db/_baz/foo/_show/docid > /db/_baz/foo/_files/index.html > > Before we commit / before 0.9.0: > > This patch is a big enough change that I think we should vote on it > before I commit it. However, I'd like to get it in before 0.9.0 to > avoid future confusion where trunk is incompatible with API clients > and applications designed to run on our latest release. +1 (for the general idea of the patch after refining the API). Cheers Jan --