On Mon, Mar 9, 2009 at 1:40 PM, Paul Davis <paul.joseph.da...@gmail.com> wrote: > On Mon, Mar 9, 2009 at 12:58 PM, Christopher Lenz <cml...@gmx.de> wrote: >> On 05.03.2009, at 23:34, Jan Lehnardt wrote: >>> >>> On 5 Mar 2009, at 21:38, Christopher Lenz wrote: >>>> >>>> Actually, I'd go even further, and suggest that the "show" and "list" >>>> features should be part of that CouchApp plugin, and not actually included >>>> with CouchDB itself. You really only need those features when you're >>>> developing CouchApp-style applications. Moving them into a corresponding >>>> plugin would help keep CouchDB itself lean and clean. >>> >>> show and list are useful in the non-couchapp case. a list gives you >>> RSS/Atom feeds on views (say blog posts or events) for free. a show would >>> help you to mangle your data for other systems that e.g. like to consume >>> XML. I like that this can be done without a middleware layer. >>> >>> I'm +1 on modularizing additional features on the Erlang level, but show & >>> list I'd consider core CouchDB and -1 on making them optional. >> >> "core" is a strong word for something where you just said "I like that this >> can be done without a middleware layer". >> >> I'm not convinced. I'm talking about the case where you already have >> "middleware" anyway -- if you don't, you have a CouchApp-style app. >> Generating Atom, HTML, and such is pretty darn convenient for me with Python >> and Genshi, I don't think moving that into CouchDB show/list functions will >> buy me anything. And since I'm hiding CouchDB itself behind that middleware >> I'd have to proxy the CouchDB responses through it anyway. >> >> Note that I'm just stating my opinion, I knew it'd be controversial, >> especially with the CouchApp fans :P >> I'm totally willing to accept the majority preference here, which seems >> pretty clearly in favor of show/list in core. >> >> Cheers, >> -- >> Christopher Lenz >> cmlenz at gmx.de >> http://www.cmlenz.net/ >> >> > > My personal opinion is that we should strive towards making CouchDB > modular and easily configurable. (ie, no need to stop the server and > edit an ini file). As part of this work I could see having a contrib > directory of modules that are included in trunk and available on any > default install. Giving a nice page in Futon that was all pretty and > listed the available modules that could be enabled and disabled at > runtime would be awesome. > > Following that, the _list/_show bits seem like they would fit quite > nicely into such a framework as a poster child of the modular couch. > And we could even ship couchdb with _show/_list turned on by default > if the community so desires it. > > Also of note is that the _show/_list code is pretty self contained and > doesn't affect the deeper internals other than to point out where > things could be made a bit more generic for reuse which has been > beneficial so far. > > HTH, > Paul Davis >
I forgot to mention I'm a 0 on whether _show/_list is part of CouchDB 'core'. I'd be +1 on making sure they get distributed with CouchDB though, the naming thing I leave to other people. Hopefully some future updates to make us more OTP compliant will make this definition game disappear completely.
