Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of jason@jasondavies.com
 designates 89.145.97.179 as permitted sender)
Message-Id: <7A65E6F9-8887-40F1-B434-D25B514F0092@jasondavies.com>
From: Jason Davies <jason@jasondavies.com>
To: dev@couchdb.apache.org
In-Reply-To: <D10167F8-E0F8-4510-870B-735A5B95C3B3@apache.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Wed, 4 Mar 2009 16:34:24 +0000
References: <329362532.1236140156091.JavaMail.jira@brutus>
 <D10167F8-E0F8-4510-870B-735A5B95C3B3@apache.org>
Subject: Re: [jira] Created: (COUCHDB-280) relative links between resources
 provided by design docs

On 4 Mar 2009, at 16:16, Jan Lehnardt wrote:

> 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

I also prefer _render.  How about doing the analogous to what we do  
for JSON docs and views, i.e. something like:

/db/_design/foo/_render/renderfun/docid
/db/_design/foo/_render/renderfun/_view/viewname

This would work at the moment because slashes in the docid URL are URL- 
encoded, i.e. in the (unlikely) event of a doc with an id of "_view/ 
viewname", it would be rendered via _render/renderfun/_view 
%2Fviewname, hence no collisions.  Even if we were to allow unescaped  
slashes in the docid URL e.g. _render/renderfun/foo/bar/baz/ where the  
docid is "foo/bar/baz/", we still maintain _* as a reserved namespace  
so there's no danger of anyone creating a document with docid "_view/ 
*", hence I think is pretty future-proof in that sense.

>
>
> 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).

+1 FWIW :-)

--
Jason Davies

www.jasondavies.com