Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 25D5A10C49 for ; Sun, 1 Dec 2013 00:20:23 +0000 (UTC) Received: (qmail 96003 invoked by uid 500); 1 Dec 2013 00:20:22 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 95969 invoked by uid 500); 1 Dec 2013 00:20:22 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 95961 invoked by uid 99); 1 Dec 2013 00:20:22 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 01 Dec 2013 00:20:22 +0000 Received: from localhost (HELO mail-ob0-f176.google.com) (127.0.0.1) (smtp-auth username chewbranca, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Sun, 01 Dec 2013 00:20:22 +0000 Received: by mail-ob0-f176.google.com with SMTP id va2so11322364obc.35 for ; Sat, 30 Nov 2013 16:20:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=EhrTrnEyk6lWrG9LpVxTC/iPouzBEndOzrffubT1dOU=; b=W1TkHIAuY8tFWBkmgRGprlR2bI6M3k/LUTHmh8kCucUt0ZIr2upfISTQFsTaUZCkHD Do7mWkIgR7WTyZefOofTVIYgtthHLf2V2yO8MY6hxSzKnV7tftzwbVY7rrc/FUlSRtRk MomTjdAMKBnkRMrckjHCkr9q/VJ0SuVr9uwX9IvtJeAOQ4kAyuT/FtR0cwiGTQyd7O/e ZReEaKTQPbBe+x84kKsTx79auNWR7olhEZvFQwADunXQcgD+1rirbCURHrgEv1D2h2Jo uIQv46vRtBdjgSj1cr4YbBg3WoWVc6iHjYwiGWOVkKDpM5kbOhcZISLcQxV6ZE1ZjUqc XFug== MIME-Version: 1.0 X-Received: by 10.182.99.231 with SMTP id et7mr48976235obb.10.1385857221552; Sat, 30 Nov 2013 16:20:21 -0800 (PST) Received: by 10.60.51.168 with HTTP; Sat, 30 Nov 2013 16:20:21 -0800 (PST) In-Reply-To: References: <529A19BF.1060209@lymegreen.co.uk> <2B31B8CB-2E3E-4AAD-A4C8-93C614A109F5@programmazione.it> <6364DA60-4B97-41CA-ACB0-29F3D7BAC4D5@programmazione.it> Date: Sat, 30 Nov 2013 16:20:21 -0800 Message-ID: Subject: Re: [discuss] couchapp.org down, couchapp.org spammed From: Russell Branca To: dev@couchdb.apache.org Content-Type: multipart/alternative; boundary=089e0158a92e6671d504ec6e07d2 --089e0158a92e6671d504ec6e07d2 Content-Type: text/plain; charset=ISO-8859-1 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 On Sat, Nov 30, 2013 at 2:57 PM, Filippo Fadda < filippo.fadda@programmazione.it> wrote: > List and show are not stored procedure. We already discussed that Benoit. > > http://wiki.apache.org/couchdb/Formatting_with_Show_and_List > > From the documentation: "Show and list functions are side effect free and > idempotent. They can not make additional HTTP requests against CouchDB. > Their purpose is to render JSON documents in other formats." > > Apples are not pears. I'm not buying it, stop selling list and show like > stored proc. A stored procedure, in general, is not side effect free or > idempotent. > > > If you just want a database then any KV is enough for your purpose. If > now > > you want a DBMS which at least I want, then you probably want a way to > > store procedures and such to adapt the query language to your needs. > Guess, > > what is the purpose of lists and shows? > > Not in the way they are. To me, actually list and show are useless. I'm > sorry, this is what I think. Can we just move on? > > -Filippo --089e0158a92e6671d504ec6e07d2--