couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Broerse <i...@martinbroerse.com>
Subject Re: Whither CouchApps (Was: views failing due to fabric_worker_timeout and OS process timed out)
Date Mon, 27 Feb 2017 09:58:11 GMT
Hi Jan,

If we split thinking about CouchApp in the hosting part and the backend
coding part it would not hurt our usage if we lose the coding part. The
coding part we need on the backend like password resetmails and other
scheduled tasks are not there so the coding part needs to be more powerful
before we can use it. We can solve this tasks with OpenWhisk so perhaps
keep the hosting feature and lose the rest?

The Ember guys at LinkedIn found it is faster to eval javascript loaded as
strings than loading the javascript from the backend. We have not tested
this yet but if this is true we can perhaps bootstrap javascript apps from
strings hosted in CouchDB but we still need the CouchDB hosting part for
the bootstrap code.

So in the future we are for keeping the hosting and lose the rest.

- Martin

On Mon, Feb 27, 2017 at 9:18 AM, Jan Lehnardt <jan@apache.org> wrote:

> Hi Martin,
>
> thanks for your comment.
>
> > On 27 Feb 2017, at 07:52, Martin Broerse <info@martinbroerse.com> wrote:
> >
> > We use the hosting from couchapp for many projects via
> > https://www.npmjs.com/package/ember-cli-deploy-couchdb so keep it in
> > couchdb. To replace excel sheets in businesses it is super you don't
> need a
> > separate hosting stack. An example couchapp hosted only on Cloudant:
> > https://bloggr.exmer.com
>
> Existing versions of CouchDB that support CouchApps aren’t going away,
> and I’m sure Cloudant will keep things around for a while, too.
>
> This is about the future of CouchDB and the non-existent developer
> time that is required to maintain these features as CouchDB evolves.
>
> Best
> Jan
> --
>
>
> >
> > - Martin
> >
> > On Sun, Feb 26, 2017 at 6:40 PM, Jan Lehnardt <jan@apache.org> wrote:
> >
> >> Aurélien,
> >>
> >> I see that at least at some point you were subscribed and participating
> on
> >> the couchapp@couchdb.apache.org mailing list. From the stated goal of
> the
> >> list (find a new technical foundation for CouchApp) and the lack of
> >> significant engagement (users and devs alike) there, it should have been
> >> clear where this is headed.
> >>
> >> And just to reiterate:
> >>
> >> 1. CouchApp was an attempt to revolutionise web development as we know
> it.
> >> — It failed, in like 2011.
> >>
> >> 2. It was designed in a world before Node.js. Most folks who want to do
> >> JavaScript and CouchDB have moved on.
> >>
> >> 3. There are SEVERE technical limitations, most of which aren’t as bad
> as
> >> a view index generator, but VERY bad for anything OLTP (think CGI from
> 90s).
> >>
> >> 4. The features are unmaintained at this point, future refactorings
> might
> >> make the unavailable (e.g. in a http layer rewrite). The last
> significant
> >> work on the relevant code is 5-6 years in the past.
> >>
> >> 5.We invited the CouchApp community to step up and build a future-ready
> >> version of CouchApps, complete with a design direction and own mailing
> >> list.. Nobody stepped up, and at the end of the day, a project goes
> where
> >> developers can spend time.
> >>
> >> 6. and to be clear, we are talking about: 1. _show & _list 2. _update
> >> funs, 3. rewrites // for the time being, we’ll keep validate_doc_update
> and
> >> filter functions, but plan to replace them with per-doc access control
> and
> >> Mango schema enforcement. The idea of design docs, or attachments on
> >> documents are not going away.
> >>
> >> In terms of ease of building web apps: a Node.js process running next to
> >> CouchDB is only minimally more setup hassle and gives you:
> >>
> >> 1. The same baseline features, plus a lot more.
> >> 2. A simple app building model.
> >> 3. A RICH ecosystem of third party libraries.
> >> 4. WAAAAAAAY better performance and scalability.
> >> 5. A future for you to do just the things you are already doing without
> >> moving to another platform.
> >>
> >> Best
> >> Jan
> >> --
> >>
> >>
> >>
> >>> On 25 Feb 2017, at 18:22, Aurélien Bénel <aurelien.benel@utt.fr>
> wrote:
> >>>
> >>> Hi Joan,
> >>>
> >>>> Your email is aggressive, and your apology is not accepted.
> >>>
> >>>
> >>> I didn’t want it to be. I beg you for your pardon then.
> >>> My frustration was real, but I can assure you that I am not an
> >> aggressive person.
> >>> There would not have been any ambiguity in my mother language :
> >>> discussing technologies in a foreign language is one thing, expressing
> >> your feelings is another.
> >>>
> >>>> This topic has been discussed to death on the mailing lists and I am
> >> not going to be pulled into a retread of this argument.
> >>>> http://mail-archives.apache.org/mod_mbox/couchdb-dev/
> >> 201702.mbox/%3CB6DB98EC-42B1-4960-9E43-257F040238F1%40apache.org%3E
> >>>
> >>> I’m just a « user »… a very dedicated and passionated user (I’m
in the
> >> top 10% on StackOverflow about CouchDB and I taught CouchDB to more than
> >> 150 french software engineers), but a user. That’s why I never
> subscribed
> >> to the « dev »  mailing list (or for a very short period of time). I now
> >> understand that I should have, but it’s too late.
> >>>
> >>> My frustration is as high as has been my passion for six years for this
> >> incredibly interesting project.
> >>> I respect the board decisions but now I will have a hard time finding
> >> money (which is sparse in academic research) to move all of our
> software to
> >> a different technology stack and arguments to explain to all of my
> >> collaborators that I bet on a technology stack that got rapidly
> deprecated.
> >>>
> >>> Thank you for your understanding.
> >>>
> >>>
> >>> Best regards,
> >>>
> >>> Aurélien
> >>
> >> --
> >> Professional Support for Apache CouchDB:
> >> https://neighbourhood.ie/couchdb-support/
> >>
> >>
>
> --
> Professional Support for Apache CouchDB:
> https://neighbourhood.ie/couchdb-support/
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message