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 14:34:50 GMT

Firstly, let me thank you all on the great work you have done with 
couch.  Thanks.

Secondly, regardless of JChris/domain ownership/personal likings etc;  
Is there any possibility of improving (or changing) couchapp (or its 
replacement's) functionality?

For example:

1. Javascript stored on the file system must match the javascript stored 
on couch (i.e. no including common code through comments in view files) 
- this is required if you want reliable version control - and be able to 
match each code change with behavior change and vice versa.

2. Support unit test and profiling support (or at least permit them 
without having to modify the code managed through couchapp).  There has 
been quite a bit of work on unit tests/linting tools etc, and the way 
couchapp works makes it difficult to take advantage of these.

Of course these are my desires - and I understand you and others may not 
share it.  And you have my apologies in case any of these topics are 
discomforting in any way.

I will shut up now.


On 12/02/2013 05:35 AM, Andy Wenk wrote:
> why don't we stop the discussion here and think about how or
> at least the contents can be maintained further? There are only some points
> to clarify:
> - do we (the CouchDB community) want to maintain the contents? Regardless
> if it is "part" of CouchDB or not (this is a never-ending discussion imho)
> - who will start to speak with JChris about the domain?
> - where do we want to host the domain or contents?
> I have a personal interest to keep and / or it's contents
> running because that was my first contact with CouchDB, Benoit and JChris.
> I don't want to see the awesome work die!
> Cheers
> Andy
> On 2 December 2013 02:50, Vivek Pathak <> wrote:
>> Hi
>> 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 etc).
>> 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
>> belongs.js
>> 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 support).
>> 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.
>> Thanks
>> Vivek
>> 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