On Aug 2, 2010, at 1:20 PM, Paul Davis 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.
Right. This would be the 1) side of what I talked about up there, as it'd be useful for CouchDB 2.0. For that, maybe a sandboxed Node.js implementation of the show and list, etc, would be the best solution. But I think it'd be better to stick to a single runtime, so if we use emonk for views, we should also use it for show and list. Chris
