From dev-return-6381-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Sun Sep 13 17:55:38 2009 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 21319 invoked from network); 13 Sep 2009 17:55:38 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 13 Sep 2009 17:55:38 -0000 Received: (qmail 60295 invoked by uid 500); 13 Sep 2009 17:55:37 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 60187 invoked by uid 500); 13 Sep 2009 17:55:37 -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 60177 invoked by uid 99); 13 Sep 2009 17:55:37 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 13 Sep 2009 17:55:37 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jchris@gmail.com designates 209.85.212.171 as permitted sender) Received: from [209.85.212.171] (HELO mail-vw0-f171.google.com) (209.85.212.171) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 13 Sep 2009 17:55:26 +0000 Received: by vws1 with SMTP id 1so1469811vws.13 for ; Sun, 13 Sep 2009 10:55:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=pRhmi/trDDoA//qUeYz8f4f20sfRSq44lLhNRs8JRUM=; b=x2KYOi+QVAuJHF/sWrxisNBjnSmyJSYMqPZ/I4ODTIfVhGcOe2lK4vi0bJ4FVaD302 1okbsdZ714Y/LBMEHMd3xWhEJCvCtESZyRJuS98Bi8qkRjm9vKm+XlXTuLc/aCUS4IQQ +srNcJ4ucxxyf9AT1PmgLaX3BfRzGuGoeOxTY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=NhrhFSXnba+I4iuK5WBSq1H8pb0fbRK+y0pNrEnUbwhjztYMd+zUrGdibPwhw0/d9t q0a98cTnsDHcGpCiAVaSHFbFbgTaweSRDoPc7eDI3swU9jhcAwQnzyJbMFGmsGZsGP1U MpYXAI07oxrPcAuwz5KKHjz+6/EpRvvfIQ8lA= MIME-Version: 1.0 Sender: jchris@gmail.com Received: by 10.220.108.232 with SMTP id g40mr6456817vcp.50.1252864505481; Sun, 13 Sep 2009 10:55:05 -0700 (PDT) In-Reply-To: References: Date: Sun, 13 Sep 2009 10:55:05 -0700 X-Google-Sender-Auth: e2b7c048c7cd9709 Message-ID: Subject: Re: POST/PUT on _show vs POST/PUT on _update + GET on _show From: Chris Anderson To: dev@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On Sun, Sep 13, 2009 at 10:37 AM, Vlad GURDIGA wrote: > On Sun, Sep 13, 2009 at 1:17 AM, Benoit Chesneau wr= ote: >> 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" =A0and >> 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. > The notion is that by allowing non JSON updates, we are available to a wider range of clients without using a middle tier. So in particular a browser with JavaScript turned off could make a regular form post to an _update handler and it would manage parsing it into JSON and saving it. I'm not sure about whether update should be the same as _show - it may be more restful in some cases, but as Jan mentioned, there are times when a single update request might result in multiple documents, in which case it's own resource makes more sense. > 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. > --=20 Chris Anderson http://jchrisa.net http://couch.io