Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of ipad.wenk@gmail.com designates
 209.85.216.43 as permitted sender)
MIME-Version: 1.0
Reply-To: andy@nms.de
Sender: ipad.wenk@gmail.com
In-Reply-To: <529BE783.5030601@orgmeta.com>
References: 
 <CAJNb-9q+34-UwLBv24mJS6xN-n7czZ_mFp4Z7KpaouOXW1FNrg@mail.gmail.com>
 <D4B09FF1-64F5-440B-BC1E-36A2282B9AAC@programmazione.it>
 <529A19BF.1060209@lymegreen.co.uk>
 <2B31B8CB-2E3E-4AAD-A4C8-93C614A109F5@programmazione.it>
 <CAHdjipLOr3p_Nj3MD21bP8VCMbrt8mHvgeGa4fGi4eYdK6a9GA@mail.gmail.com>
 <6364DA60-4B97-41CA-ACB0-29F3D7BAC4D5@programmazione.it>
 <CAJNb-9r==44m1CGy3iSwxcrOvq+_YD_UZ4rGzyKtPWEx442SoQ@mail.gmail.com>
 <F86AC6A6-8B31-44AC-B0C6-9AE80749A632@programmazione.it>
 <CAFUSCh8fJJLePaNMfM5QhxHd-ND-f9-F9eZuY1VcMu6EZQqq1g@mail.gmail.com>
 <CAHdjip+u997DPT8PK5v87cEYryhjkx6Uh_=oSQzWGTRt_4n2ag@mail.gmail.com>
 <529BE783.5030601@orgmeta.com>
From: Andy Wenk <andy@nms.de>
Date: Mon, 2 Dec 2013 11:35:40 +0100
Message-ID: 
 <CADA9kr-0FLtojsb4cfW_HQMTithf6SXL_aiqwOjgqhEKb8nbog@mail.gmail.com>
Subject: Re: [discuss] couchapp.org down, couchapp.org spammed
To: "dev@couchdb.apache.org" <dev@couchdb.apache.org>
Content-Type: multipart/alternative; boundary=001a11c2b762f8579204ec8abe52

--001a11c2b762f8579204ec8abe52
Content-Type: text/plain; charset=UTF-8

why don't we stop the discussion here and think about how couchapp.org 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 couchapp.org 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 <vpathak@orgmeta.com> 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:
>  update_field.py -u $(COUCH) $(DBNAME) _design/ids views.belongs.map
> belongs.js
>
> This pushes belongs.js to key db["_design/ids"].views.belongs.map ,
> 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 (
> http://wiki.apache.org/couchdb/HTTP_view_API#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 <chewbranca@apache.org>
>> wrote:
>>
>>> In its current form, couchapp.org 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 couchapp.org. 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",
>>> couchapp.org. 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.
>>
>> --
>> ,,,^..^,,,
>>
>
>


-- 
Andy Wenk
Hamburg - Germany
RockIt!

http://www.couchdb-buch.de
http://www.pg-praxisbuch.de

GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588

--001a11c2b762f8579204ec8abe52--