TL;DR: Allow list, show and update (lsu) functions return special object
for chaining requests. In short, I propose lsu fns could return object of
same structure as JS rewrite does:
{path:"...", method:"...", body:"..."}.
If query server receives this kind of object as lsu fn result, user
connection kept open and next internal request performed. We can use .body
as accumulator inbetween requests.
This feature allows multistep map/reduce, deep data manipulation and
analysis, sites with server-rendered composite pages, service DB scripts
and so on.
Background
=========
There can exist several approaches for multi-requests. Most of them tend to
use some kind of new DSL to describe requests server should perform, and in
which order results should be returned. In some cases I saw attempts to add
kinda postprocessor at the end: adapted _list or so.
Also despite CouchDB users understand inevitable penalties of multi-request
approach, feature is highly needed.
Multistep map/reduce
================
If we allow lsu functions to define, where to go next after they finished,
we can chain several query server requests during one user request. To make
our chain a reducer, we must have accumulator.
Actually, correctly formatted .body property could be used without adding
new functionality. For example, we can reserve key acc in form-encoded
.body and pass intermediate results using this key.
To avoid parse/serialize acc data to form-encoded string we can add .acc
property to the returned object, or smth like this.
Chunked response
===============
For chains, intended to generate HTML response, we can go without
accumulator at all. Each part of chain sends its part of response, and last
chain member ends up user connection.
Example: view1/list1 sends headers and page menu, then rewrites to
view2/list2 which sends main article and rewrites to view3/list, which
sends readmore section and footer. All in one user request.
Pseudographics, illustrating both chunked response and reduce approach:
http://bit.ly/1NrTddP
Service scripts
===========
Since we can perform update fns along the chain, we can write scripts like
‘Copy all docs of type N from DB1 to DB2, removing props X, Y and Z from
docs.’
Performance
==========
Well, at most average ) If we could cache req.info along chain and optimize
.body/.form processing, it might improve situation a little. But main lags
appear during Erlang<->JS communication, not JS executuion per se.
Implementation and niceties
=====================
Implementation doesn‘t seem to be very difficult – only existing well known
paradigms are used, nearly nothing new added.
Think I could try to implement it, my modest Erlang kung-fu should be
enough for features described.
To note: these features will make CouchDB Turing complete, really.
Opinions welcome. Preliminary discussions showed both negative and positive
feedback, so putting it to public.
ermouth
