On Tue, Sep 15, 2009 at 8:46 AM, Chris Anderson <jch...@apache.org> wrote: > On Mon, Sep 14, 2009 at 9:47 PM, Vlad GURDIGA <gurd...@gmail.com> wrote: >> Thank you Jan for the comment. >> >> >> On Sun, Sep 13, 2009 at 8:58 PM, Jan Lehnardt <j...@apache.org> wrote: >>> >>> On 13 Sep 2009, at 19:37, Vlad GURDIGA wrote: >>> >>>> On Sun, Sep 13, 2009 at 1:17 AM, Benoit Chesneau <bchesn...@gmail.com> >>>> wrote: >>>>> >>>>> On Sun, Sep 13, 2009 at 10:12 AM, Vlad GURDIGA <gurd...@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 >
