On Mon, Sep 14, 2009 at 9:47 PM, Vlad GURDIGA <[email protected]> wrote: > Thank you Jan for the comment. > > > On Sun, Sep 13, 2009 at 8:58 PM, Jan Lehnardt <[email protected]> wrote: >> >> On 13 Sep 2009, at 19:37, Vlad GURDIGA wrote: >> >>> On Sun, Sep 13, 2009 at 1:17 AM, Benoit Chesneau <[email protected]> >>> wrote: >>>> >>>> On Sun, Sep 13, 2009 at 10:12 AM, Vlad GURDIGA <[email protected]> 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. 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
