On Mon, Mar 9, 2009 at 10:42 AM, Paul Davis <paul.joseph.da...@gmail.com> wrote: >> >> 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. >>
I think they are a pretty good poster child as it is. Currently to disable them you need only comment out two lines in the ini file. The code could be arranged in different directories but if we want to do that it can wait for OTPification. On Mon, Mar 9, 2009 at 10:01 AM, Christopher Lenz <cml...@gmx.de> wrote: > But how is that relevant to applications that do *not* follow the CouchApp > model, but rather have a traditional web/app-server sitting in front of > CouchDB? I've been thinking about examples of this for a couple of days. There are a few that I've found that are perfect for CouchApps even in a middleware deployment. One of them is document-signing, as is being discussed on the list right now. It'd just be a matter of a show function, which could return a canonical JSON string for a given JSON document (or subfield of that document) to be signed by the client. Write once, reuse in any Couch, no messy Erlang patches or custom config to deal with. I'm sure there are more examples along these lines. Another example (that Paul has already experimented with) is server-side filters. Say I want all the recipes that involve cilantro and strawberries. For ingredient in ingredients emit(ingredient, ingredients) and filter in a list function (that serves JSON) to save bytes over HTTP. It's just another tool in the pragmatic Couch-developers toolkit. Thanks for the support, Chris, even though it's not your use case. >From my vantage point CouchApp style development is garnering a lot of interest, some of it quite heavyweight. My strategy for committing will be - commit to the branch I started today. Notify the dev and user lists about the breaking change to view urls. Merge the branch to trunk. I don't see much point in waiting between the notification of the breaking change and the merge - people who want time to convert their client libraries can hover at the pre-merge revision until they are ready to leap to 0.9. Does this seem sane to you all? Chris -- Chris Anderson http://jchris.mfdz.com
