I’d like to raise QS functions deprecation question again, in a somehow different aspect.
Statistically, ‘couchapp’ term has unfortunate history: many tried what they thought were couchapps, most expected too much – and were bitterly disappointed. I have better experience with couchapps and derivatives, but technologies and tooling used are very far from mainstream concepts. Anyway, we played a lot with QS, and discovered that _list, _update and, later, js _rewrite have another point of application, much more significant than rendering HTML in a cumbersome manner. QS functions, being distributed with main data flow, allow comprehensive in-place data pre- and post-processing, very unique feature across DB landscape. So, probably it would be better not to deprecate/remove those endpoints in Couch 3, but just ditch the ‘couchapp’ term in favor of something like ‘data processing extensions’. Seems, QS functions in current state require very minor maintenance and have nearly zero bugs. So why spend time amputating working parts, shouldn’t it be better to transform them into clearly presented advantage? I mean changes in docs, removing ‘couchapps’ in favor of ‘processing extensions’, maybe introducing less expensive requestObj, etc. Clarifying language:"erlang" usage might also be valuable. Anyway, creative work, not destructive. ermouth
