On Fri, Feb 27, 2009 at 12:50 AM, Brian Candler <b.cand...@pobox.com> wrote: >> One way to fix this it to give the resources made available by a >> design document a common root. This means we can use hrefs like >> "_show/docid" to link to a show function from an attachment. So we >> get paths like this: >> >> /db/_design/foo/_view/bar?limit=10 >> /db/_design/foo/_show/docid >> /db/_design/foo/index.html > > Does this imply that attachment names can no longer be permitted to start > with an underscore? If so I'd say that's very reasonable, being consistent > with the rule for docids (*). > > You could consider that attachments starting with an underscore are > "virtual" attachments, generated on demand. > > ISTM that the overall goal of this proposal is to make all the output of > _design/foo accessible under the _design/foo namespace, so that views and > lists can easily link to each other with relative URLs, not knowing that the > design document's name is "foo".
You hit the nail on the head here. > > This also seems sensible to me. However, perhaps the name "_design" is no > longer meaningful. The namespace would no longer cover just the definition > of the map/reduce and list/show functionality, but also all of its output. > When I first came to the realization that to make relative links work, the urls would have to get longer, I thought "hey, let's change _design to _app" I didn't bring it up in the first round because I didn't want to muddy the waters. But now that it's brought up... Hey, let's change _design/ to _app/ > Ha, there's another bikeshed to discuss :-) > sigh. > (*) Such as rule would also allow other potential future uses, e.g. > > /db/docid/_plugin > that is kind of a neat consequence of a no _rule for attachments. The other alternative is to keep attachments in a dedicated namespace /db/docid/_attachments/index.html -- Chris Anderson http://jchris.mfdz.com
