couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vivek Pathak <>
Subject Re: [discuss] down, spammed
Date Mon, 02 Dec 2013 01:50:59 GMT

I agree quite a bit about the coucapp. Hence couldnt help but comment.

Couchapp does seem to have quite a few rough corners feel to it - when 
compared to the soundness of couchdb as a whole (even without bigcouch 

I have been using a self written tool to push view/list/show code to 
couchdb from using a makefile for my project.   A sample line from the 
makefile is as follows:

belongs_view: -u $(COUCH) $(DBNAME) _design/ids 

This pushes belongs.js to key db["_design/ids"] , 
recursively creating any intermediate json objects as needed.

It has worked well for me because I get to edit my javascript code in 
any editor.  And unlike couchapp, I do not need to install a python 
package (particularly one which does not seem to have heavy community 

The use case for couchapp is mentioned as sharing code between views ( 
).   At the cost of adding shared code into common js modules 
explicitly, I get the convenience of "what you see is what you get" - 
unlike the inclusion of code through JS comments in couchapp.

If the overall idea of having a standalone tool is attractive, I can 
surely improve it a bit (eg: usage line can improve, etc)  and share 
more widely.  It anyway was created under an apache 2 licence.


On 11/30/13, 10:33 PM, Alexander Shorin wrote:
> On Sun, Dec 1, 2013 at 4:20 AM, Russell Branca <> wrote:
>> In its current form, is a relic that has been mostly abandoned
>> and is not maintainable by the community. I strongly feel we should move
>> the couchapp documentation into official documentation. I see two relevant
>> points of interest in this discussion. First is the notion of couchapps as
>> the self contained application platform that utilizes show/list functions,
>> and whether these should be included in CouchDB. I don't think this is the
>> important issue at hand.
>> The bigger issue is that the defacto method of defining design documents is
>> to use one of the many "couchapp" tools, and the only place this is
>> documented as a whole is This is a disservice to the
>> community, and one that needs to be resolved. This is a constant source of
>> confusion to new users who quickly realize the futility of defining design
>> docs in the browser, and get lost when told "just use a couchapp", and then
>> they inevitably end up clicking on the top google result for "couchapp",
>> We need to have this properly documented in the official
>> documentation so that the process is fully defined for new users.
>> A couple of options for approach would be to formalize the folder
>> definition of a couchapp and list tools known to be compatible, or to
>> officially bless a tool like Erica. While I do want to see Fauxton provide
>> powerful editors for all the different function types, I don't think this
>> is sufficient as people typically want to keep their design docs raw code
>> under SCM. Whatever approach is taken, I think the number one priority here
>> is ensuring proper documentation explaining to users best practices for
>> defining and maintaining design docs.
>> -Russell
> +1 and actually I'm only waiting for rcouch merge and having erica as
> builtin tool. There is already big place to land all the stuff in
> source code tree and even named also as "couchapp" since it provides
> huge potential for more interesting and rich content rather than just
> "ddoc" or similar.
> --
> ,,,^..^,,,

View raw message