ermouth commented on issue #1534: proposed 1.x deprecations URL: https://github.com/apache/couchdb/issues/1534#issuecomment-412367604 > Could your embedded RasPi update function be written declaratively? Very unlikely, devices do not post json. For now both `_update` and `_rewrite` as a fn are able to chop up requests having binary body, and then decide. I have no doubts any DSL making this kind of work will be either useless for other scenarios, or too complex if it wants to cover everything. DSLs are not a substitute for yet unknown tasks. Any DSL is domain-specific, or it’s a cumbersome mess. > The UNIX philosophy applies to CouchDB as to any other program Indeed, however ‘do one thing’ is, looking at most of modern really user- and dev-friendly SW, bit unpopular from UX point of view. This rule was good at CLI-only times, and those times are gone. For now, standing for this rule mostly increases transaction costs: the approach of loosely stitching things together is good for scripts, but often induces heavy deployment and impedance alignment costs for continuous systems. Also let me remind another Unix rule that still stands, the rule of diversity: **Make programs flexible, allowing them to be used in ways other than those their developers intended.** > The same goes for a proxy server like HAproxy or Nginx when it comes to proxying, vhosts and rewrites I have nothing to say about vhosts and proxying, we never used them seriously as those settings are not replicatable, but as for rewrites... What about deployment? If you have hundreds of nodes which are not intended to be members of a cluster, updating external proxy rules is a serious pain with immense number of uncomfortable (or just dangerous) subtleties. With delivering API wiring using regular data flow deployment is just one click, because it uses most powerful feature of Couch: replication. Utils like nginx-sync do not stand even near. > So far, the big place he's stuck is implementing lists It would be nice to have more info, no one can help having no description of a problem. Should removing or simplifying `.info` obj ease the task? It was done for rewrites as a fn, and this trim, aside of other effects, gives good perf improvement comparing to other QS stuff. Actually, CouchDB 1.6.1 patched with JS rewrites and called through rewrite JS function is still in most cases bit faster then naked single-node 2.x. > Alternately, what would Mango need added to it to give you sufficiently improved list functionality to fully replace JS lists? Full replacement is impossible, or you will make new DSL just another programming language. However if narrow the scope to simplest cases and JSON-only, joins and reducers are obvious answer. If former is more or less clear and implementable, the latter just does not fit well into DSL concept except simplest cases. So, summing up: I have nothing to say about non-replicatable features or features proven to be buggy and unreliable. But I think most features using benefits of syncing code with data flow better be kept.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
