couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vlad GURDIGA <gurd...@gmail.com>
Subject Re: POST/PUT on _show vs POST/PUT on _update + GET on _show
Date Wed, 16 Sep 2009 03:05:36 GMT
On Tue, Sep 15, 2009 at 8:46 AM, Chris Anderson <jchris@apache.org> wrote:
> On Mon, Sep 14, 2009 at 9:47 PM, Vlad GURDIGA <gurdiga@gmail.com> wrote:
>> Thank you Jan for the comment.
>>
>>
>> On Sun, Sep 13, 2009 at 8:58 PM, Jan Lehnardt <jan@apache.org> wrote:
>>>
>>> On 13 Sep 2009, at 19:37, Vlad GURDIGA wrote:
>>>
>>>> On Sun, Sep 13, 2009 at 1:17 AM, Benoit Chesneau <bchesneau@gmail.com>
>>>> wrote:
>>>>>
>>>>> On Sun, Sep 13, 2009 at 10:12 AM, Vlad GURDIGA <gurdiga@gmail.com>
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.
>>
>> 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.

That is exactly what I was worried about!

I think that not giving the application developers too many
opportunities to screw up is a very good characteristic of a
development platform.

Thanks a lot for clearing this up!

>
> 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
> apps.
>
> --
> Chris Anderson
> http://jchrisa.net
> http://couch.io
>

Mime
View raw message