> On 9. Jul 2019, at 08:56, Johs Ensby <j...@b2w.com> wrote:
>
> Chintan,
>> On 9 Jul 2019, at 05:50, Chintan Mishra <chin...@rebhu.com> wrote:
>>
>>> CouchDB 1.x is no longer supported, even for security updates.
>> Johs had some interesting points regarding 1.x and their stability. Would
>> you mind sharing those?
> CouchDB 1.x can run uninterrupted for years. We used it to create quite
> complex web sites like this https://www.goltens.com This particular site has
> been managed (tech and content) by one guy spending a few hours every second
> week or so. The client, being a multinational company with most of its
> business coming through this site got nervous about their site being hosted
> on an unknown platform and managed by one guy, and commissioned a fullservice
> comms agency to move it to WordPress. They have been trying for 6 months now,
> and are still not ready.
> I'm not into IoT (yet) but working with a project in developing countries
> that could need a large number of local web servers with replication over
> mobile and service small rural centers with content and applications to
> smartphones/tablets over WiFi. CouchDB 1.x will do fine. CouchDB/PouchDB is
> good for data collection in areas with poor connectivity and there were some
> interesting early use cases, but projects like https://www.kobotoolbox.org/
> and https://five.epicollect.net/ have filled this niche.
>
> My love for CouchDB 1.x is mainly related to feature stability as a
> single-tier platform.
> - Build-in web server
> - Rewrite/vhost for easy configuration of several access points to the same
> data (Rewrite as a JS function was a big step forward for creating advanced
> routers/API servres, and is patched into 1.x here
> https://github.com/b2w/couchdb/blob/Rewrite-function/README.rst)
> - Map/Reduce indexing
> - the data on disk as one single file, just copy it, move it, back-up, drop
> it at another server
> - and single-node master-to-master replication is as simple as you can get
> data sharing, backup, staging sites, etc. automated or by manual one-click
> operations
> - direct-to-design-document deployment (robust IDE for this here:
> http://ddoc.me/)
CouchDB 2.x has and does all of these things.
* * *
Specifically, and we talked about this many many times in the past and you
continue to conveniently ignore this fact:
The JS runtime implementation in CouchDB 1.x and 2.x used the 1990s-era CGI-BIN
model, where a separate operating system process is forked for each concurrent
HTTP request accessing JavaScript resources. That means this model is only
really suitable for
10s and maybe 100s of concurrent requests (views are a special case and don’t
really factor in here). That means that it is EXTREMELY ancient and unsuitable
for modern web development. I know we have talked about this, Johs, because I’m
writing this kind of mail for the fifth time to you now. One of my previous
mails even included a design proposal for fixing all of the above and you all
even formed a couchapp sub-group here but never showed any prototypes or
started on code, let alone even commented on the design proposal I put forward.
You did nothing to advance the state of the art in 5+ years.
The technology here is SO BAD that we have deprecated it years ago, after your
group failed to take action on it, because the rest of the team didn’t have the
resources to building something decent. You all (mostly Ermouth) have gone
outside the project to solve your problems, and that is fantastic, if CouchDB
wasn’t this modular, you couldn’t even do any of those things.
Can we, pretty please, but the notion to rest that CouchDB becomes a
single-deployment modern web-application app server UNLESS a group of
developers steps up and contributes this technology.
If Ermouth’s projects are what you need, then that’s great, but unless you are
prepared to spend the time and constructively engage with the project (and
sending your 10s iteration of “here is what I think marketing is” is not what I
have in mind), please let this rest.
Instead, I’d love to see a PR to the website from you, or a blog post with a
case-study about how you use CouchDB in non-standard ways.
> Futon is very functional, but a bit primitive as admin panel. Photon is
> available as a stronger tool (better than Fauxton)
> https://github.com/ermouth/couch-photon
> Ddoc Lab and Photon (both by ermouth) are examples of apps that you can drop
> into any CouchDB bucket as single design documents.
> As such these are excellent examples of how community-generated tools of
> great value could evolve around CouchDB and extend the core project.
We’d love to discuss this, but so far, we haven’t been approached about maybe
including any of these things, so complaining about them being available and
fully usable is really not fair.
Best
Jan
—
>
> Your input was a flash of light when it comes to market orientation.
> The big platforms (AWS/Google/Azure) offer more and more developer-friendly
> solutions, but their lock-in disadvantage is a huge risk, and IoT and
> distributed systems is what the world needs for recillience.
> A leaner version of CouchDB would have a very large potential.
>
> Johs
>
>
>
