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
