On 27 Feb 2009, at 19:04, Chris Anderson wrote:
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.
The name _design is arbitrary. It is not in any way connected to "views"
in a meaningful way. Except by definition. Damien envisioned, and the
technical outline hints at this, that a design document includes all
definitions and resources for a single application (yes, CouchApps is
just a consequence of CouchDB's design :). They are meant as
"design" documents for applications, but not exclusively, see below.
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/
_app suggests that you are writing some kind of app in a _app/_design
document. It make less sense in the case where CouchDB is used as
a massive database backend. Views are likely split between multiple
design docs because of the evaluation behaviour.
I think _design is just fine.
To make a non-intrusive change for CouchApps, we could alias _app
to _design for the nicer URLs. But then, this is probably cruft that we
might want to avoid early on.
(*) 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
The only thing I don't like about this is that /db/docid/index.html is
kinda neat. I'm not a fan of Key-Value-URLing where it can be
avoided. I'd say the no _ rule is worth enforcing (and consistent
with other uses of _).
Cheers
Jan
--
