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