couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Davies <>
Subject Re: [jira] Created: (COUCHDB-280) relative links between resources provided by design docs
Date Wed, 04 Mar 2009 16:34:24 GMT
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:


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

View raw message