couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: POST/PUT on _show vs POST/PUT on _update + GET on _show
Date Tue, 15 Sep 2009 05:46:22 GMT
On Mon, Sep 14, 2009 at 9:47 PM, Vlad GURDIGA <> wrote:
> Thank you Jan for the comment.
> On Sun, Sep 13, 2009 at 8:58 PM, Jan Lehnardt <> wrote:
>> 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 <>
>>>>> 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.
> Could you please give an example or two?
>> being able to tell google's svn to ping CouchDB about a new commit
>> without resorting to proxies is very powerful :)
> I have no idea about how SVN would ping a CouchDB app. Could you
> please elaborate on this?
> I really appreciate the work you are doing guys, I'd love to get
> involved, and I'm trying to understand the flow of things here.

In the specific example, imagine a web service (A) that POSTs an
XML-blob at a URL of your choosing, when particular events occur.
Paypal's instant payment notification is one of these.

With an _update handler you can POST these directly at CouchDB and it
can parse the XML into a JSON document and save it. The same goes for
CSV, multipart form, or any other format.

> Thanks a lot!

The bigger picture we're working on is like an app server, but
different in one crucial regard: rather than let the developer do
whatever they want (loop of a list of docids and make queries, make
queries based on the results of other queries, etc) we're defining
"safe" transformations, like view, show, list and update.

By safe I mean that they have well known performance characteristics,
and otherwise fit into CouchDB's architecture in a streamlined way.

The big picture goal is to provide a way to build standalone apps that
can also be easily indexed by search engines and used via
screen-readers. Hence the push for plain-old html. I agree that you
can pretty much rely on JS getting executed (except when you can't).
Having HTML resources means CouchDB is suitable for public-facing web

Chris Anderson

View raw message