On Mon, Aug 2, 2010 at 10:20 PM, Paul Davis <paul.joseph.da...@gmail.com> wrote: >> To clear things up. >> >> There are 2 discussions happing in this thread: >> >> 1) what is the ideal API and protocol for a more capable query server? >> (especially one that can react differentially to doc update failures, can >> farm work out to multiple cores, etc) >> >> 2) how can we be backwards compatible with existing code and make it so you >> can respond to an HTML form POST by rendering "whoops, someone else edited >> that before you did, please retry", or "hey it looks like you failed the >> validation function for reason X" > > Thanks for giving me a place to respond to the other side of this thread. > > Reading through the part of this thread that deals with _list and > _show and _update and seeing how it doesn't really map onto the view > server semantics very well. > > When I think of CouchDB in abstract terms, i think of the core Erlang > code as the core of CouchDB. The view server (the map/reduce part) is > behind couchdb. Hidden from the world. > > The _list/_show/_update code sits in front of CouchDB and is more of a > friendly layer to interfacing with CouchDB from client apps. What I've > noticed is that most of the issues could be solved if the code > implementing the front side were just implemented separately. Perhaps > with access to an HTTP client that connects to CouchDB. Or something > that is more async in nature as has been suggested. > > Either way, I wonder if the best answer isn't to separate out the > responsibility of frontside and backside apps and write two sets of > JavaScript to deal with both. > > Paul Davis >
I think separation would be indeed better and maybe would ease the work of people making alternative couchapp servers. Also it would ease any work on the M/R side I think. - benoit
