couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: REST, Hypermedia, and CouchApps
Date Sat, 28 Feb 2009 09:18:54 GMT

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


View raw message