From dev-return-6383-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Sun Sep 13 17:59:57 2009 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 22238 invoked from network); 13 Sep 2009 17:59:57 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 13 Sep 2009 17:59:57 -0000 Received: (qmail 62158 invoked by uid 500); 13 Sep 2009 17:59:56 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 62073 invoked by uid 500); 13 Sep 2009 17:59:56 -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 62063 invoked by uid 99); 13 Sep 2009 17:59:56 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 13 Sep 2009 17:59:56 +0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [83.97.50.139] (HELO jan.prima.de) (83.97.50.139) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 13 Sep 2009 17:59:47 +0000 Received: from [10.0.1.8] (f053035223.adsl.alicedsl.de [::ffff:78.53.35.223]) (AUTH: LOGIN jan, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by jan.prima.de with esmtp; Sun, 13 Sep 2009 17:59:25 +0000 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v1076) Subject: Re: POST/PUT on _show vs POST/PUT on _update + GET on _show From: Jan Lehnardt In-Reply-To: Date: Sun, 13 Sep 2009 19:58:53 +0200 Content-Transfer-Encoding: 7bit Message-Id: <8A1EC718-2941-45E1-8E38-9A05EC4C078C@apache.org> References: To: dev@couchdb.apache.org X-Mailer: Apple Mail (2.1076) X-Virus-Checked: Checked by ClamAV on apache.org On 13 Sep 2009, at 19:37, Vlad GURDIGA wrote: > On Sun, Sep 13, 2009 at 1:17 AM, Benoit Chesneau > wrote: >> On Sun, Sep 13, 2009 at 10:12 AM, Vlad GURDIGA >> wrote: >>> It seams intuitive that _show actually shows you something and does >>> not handle update actions. >>> >> I agre that it in this case show isn't a good word. maybe "_page" >> and >> then "_pages" for _list but that another debate. >> >>> On the other hand why would we need an _update thing? Doesn't >>> CouchDB >>> handle that itself? >>> (Excuse me if the question is stupid, I was not on #couchdb at the >>> time when this discussion took place.) >>> >> >> >> _upate allow you to handle any input before saving them in couch like >> xml, csv whatever or it could be also use to post some doc without >> requiring ajax to do it. > > To me, keeping the server simple (which also means less complicated > and buggy) and fast looks like a very nice idea. Splitting the > computation burden between clients and server looks to me like a fair > enough trade this time. > > And, I believe that the several percent of the clients that do not > speak AJAX or cannot produce JSON should not dictate such a big change > in CouchDB. _update already exists :) And it is very useful for webhooks that we don't control. being able to tell google's svn to ping CouchDB about a new commit without resorting to proxies is very powerful :) > One reason I love CouchDB is it's simplicity. If we bring this > middle-tier-like functionality in, we will end up with something like > PHP, GCI, RoR, Java and millions of others in which you *have* to > process information in one more intermediate tier before being able to > put it into the DB. > > KISS. No worries about KISS :) Cheers Jan --