You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Jan Lehnardt <ja...@apache.org> on 2017/02/26 17:40:17 UTC
Whither CouchApps (Was: views failing due to fabric_worker_timeout
and OS process timed out)
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 <au...@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/
Re: Whither CouchApps (Was: views failing due to fabric_worker_timeout and OS process timed out)
Posted by Aurélien Bénel <au...@utt.fr>.
Hi Jan,
> 6. and to be clear, we are talking about: 1. _show & _list 2. _update funs, 3. rewrites
Thank you very much for the clarification.
As you can imagine, it is greatly needed to plan our own developments.
> 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.
If I may say so, I doubt a participative process could have work this way with no facilitator in charge from the very beginning. But be sure that I’m not here to blame anyone. And since we don’t have a time machine, this would be useless. So, let’s focus on the future.
> 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 (…)
Right. In several of our applications, we already have an ExpressJS layer in front of CouchDB in order to circumvent its limitations/constraints.
Transforming `_show` and `_list` into ExpressJS middleware shouldn’t be that hard… except for the lack of `userCtx`.
How do you plan to manage users in this new architecture?
- Where will be the right place to handle session cookies? in CouchDB or in NodeJS?
- If it is in NodeJS:
- Will `proxy_auth` become the only authentication mode?
- Will `_users` database become obsolete?
- How per-doc access-control will be designed? Only with users defined elsewhere?
On a more theoretic side, I am a bit sad of the disappearance of `_show` and `_list` since, by providing the building blocks to content negotiation (when used with rewrites.json « hacks »), they made CouchDB the ultimate illustration of HTTP and REST concepts (even better than Atom Publication Protocol!). I was so impressed by this… And I was so excited when I first provided CSV, FreeMind, BibTeX (depending on the domain) alternate representations… May I hope that in the future content negotiation could be made first class citizen in CouchDB again (even in a better – less hacky – way)?
As for the disappearance of rewrites… I was just discovering the potential (and the bugs) of the brand new JavaScript rewrite… As soon as it is born, it has to die. Wow.
> // 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.
OK. Just to be sure (because I’m not sure to understand what « NoJS mode » means exactly):
- Will JavaScript views still exist in CouchDB 3?
- If the answer is no, will Mango be the only option or will it be still possible to implement Erlang map/reduce views?
I ask this because we put much love into our CouchDB views and succeeded in getting quite efficient implementations for things that did not scale on PostgreSQL. These views are clearly out of the scope of Mango, and would probably need good skills in Erlang to be ported…
Regards,
Aurélien
Re: Whither CouchApps (Was: views failing due to fabric_worker_timeout
and OS process timed out)
Posted by Martin Broerse <in...@martinbroerse.com>.
Hi Jan,
We use the vhost and rewrite rules everywhere via
https://www.npmjs.com/package/ember-cli-deploy-couchdb . Sofa (
https://github.com/ampatspell/ember-cli-sofa) is a new project that started
using this. We are moving clients to Cloudant and because of the vhost it
is all they need to run their applications.
How is the voting for keeping this feature done?
- Martin
On Mon, Feb 27, 2017 at 12:23 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
> > On 27 Feb 2017, at 11:23, Martin Broerse <in...@martinbroerse.com> wrote:
> >
> > Hi Jan,
> >
> > By `the hosting feature` I mean the rewrite rules and the vhost. Good to
> > hear that is not going away.
>
> I said attachments are not going away. rewrites and vhosts are probably
> not going to be re-implemented in a new http layer (unless we find
> someone who wants to write the code and maintain it, *hint* *hint*)
>
> Best
> Jan
> --
>
> >
> > - Martin
> >
> >
> > On Mon, Feb 27, 2017 at 11:04 AM, Jan Lehnardt <ja...@apache.org> wrote:
> >
> >> Not sure what you mean with `the hosing feature`, but attachments are
> not
> >> going away.
> >>
> >> FWIW, I’d be in favour of having a modern CouchApp platform hooked into
> >> CouchDB, but in the past 5 years we haven’t found anyone who’d be
> willing
> >> to put in the work.
> >>
> >> Best
> >> Jan
> >> --
> >>
> >>> On 27 Feb 2017, at 10:58, Martin Broerse <in...@martinbroerse.com>
> wrote:
> >>>
> >>> 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 <ja...@apache.org> wrote:
> >>>
> >>>> Hi Martin,
> >>>>
> >>>> thanks for your comment.
> >>>>
> >>>>> On 27 Feb 2017, at 07:52, Martin Broerse <in...@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 <ja...@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 <au...@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/
> >>>>
> >>>>
> >>
> >> --
> >> Professional Support for Apache CouchDB:
> >> https://neighbourhood.ie/couchdb-support/
> >>
> >>
>
> --
> Professional Support for Apache CouchDB:
> https://neighbourhood.ie/couchdb-support/
>
>
Re: Whither CouchApps (Was: views failing due to
fabric_worker_timeout and OS process timed out)
Posted by Jan Lehnardt <ja...@apache.org>.
> On 27 Feb 2017, at 11:23, Martin Broerse <in...@martinbroerse.com> wrote:
>
> Hi Jan,
>
> By `the hosting feature` I mean the rewrite rules and the vhost. Good to
> hear that is not going away.
I said attachments are not going away. rewrites and vhosts are probably
not going to be re-implemented in a new http layer (unless we find
someone who wants to write the code and maintain it, *hint* *hint*)
Best
Jan
--
>
> - Martin
>
>
> On Mon, Feb 27, 2017 at 11:04 AM, Jan Lehnardt <ja...@apache.org> wrote:
>
>> Not sure what you mean with `the hosing feature`, but attachments are not
>> going away.
>>
>> FWIW, I’d be in favour of having a modern CouchApp platform hooked into
>> CouchDB, but in the past 5 years we haven’t found anyone who’d be willing
>> to put in the work.
>>
>> Best
>> Jan
>> --
>>
>>> On 27 Feb 2017, at 10:58, Martin Broerse <in...@martinbroerse.com> wrote:
>>>
>>> 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 <ja...@apache.org> wrote:
>>>
>>>> Hi Martin,
>>>>
>>>> thanks for your comment.
>>>>
>>>>> On 27 Feb 2017, at 07:52, Martin Broerse <in...@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 <ja...@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 <au...@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/
>>>>
>>>>
>>
>> --
>> Professional Support for Apache CouchDB:
>> https://neighbourhood.ie/couchdb-support/
>>
>>
--
Professional Support for Apache CouchDB:
https://neighbourhood.ie/couchdb-support/
Re: Whither CouchApps (Was: views failing due to fabric_worker_timeout
and OS process timed out)
Posted by Martin Broerse <in...@martinbroerse.com>.
Hi Jan,
By `the hosting feature` I mean the rewrite rules and the vhost. Good to
hear that is not going away.
- Martin
On Mon, Feb 27, 2017 at 11:04 AM, Jan Lehnardt <ja...@apache.org> wrote:
> Not sure what you mean with `the hosing feature`, but attachments are not
> going away.
>
> FWIW, I’d be in favour of having a modern CouchApp platform hooked into
> CouchDB, but in the past 5 years we haven’t found anyone who’d be willing
> to put in the work.
>
> Best
> Jan
> --
>
> > On 27 Feb 2017, at 10:58, Martin Broerse <in...@martinbroerse.com> wrote:
> >
> > 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 <ja...@apache.org> wrote:
> >
> >> Hi Martin,
> >>
> >> thanks for your comment.
> >>
> >>> On 27 Feb 2017, at 07:52, Martin Broerse <in...@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 <ja...@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 <au...@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/
> >>
> >>
>
> --
> Professional Support for Apache CouchDB:
> https://neighbourhood.ie/couchdb-support/
>
>
Re: Whither CouchApps (Was: views failing due to
fabric_worker_timeout and OS process timed out)
Posted by Jan Lehnardt <ja...@apache.org>.
Not sure what you mean with `the hosing feature`, but attachments are not
going away.
FWIW, I’d be in favour of having a modern CouchApp platform hooked into
CouchDB, but in the past 5 years we haven’t found anyone who’d be willing
to put in the work.
Best
Jan
--
> On 27 Feb 2017, at 10:58, Martin Broerse <in...@martinbroerse.com> wrote:
>
> 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 <ja...@apache.org> wrote:
>
>> Hi Martin,
>>
>> thanks for your comment.
>>
>>> On 27 Feb 2017, at 07:52, Martin Broerse <in...@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 <ja...@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 <au...@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/
>>
>>
--
Professional Support for Apache CouchDB:
https://neighbourhood.ie/couchdb-support/
Re: Whither CouchApps (Was: views failing due to fabric_worker_timeout
and OS process timed out)
Posted by Martin Broerse <in...@martinbroerse.com>.
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 <ja...@apache.org> wrote:
> Hi Martin,
>
> thanks for your comment.
>
> > On 27 Feb 2017, at 07:52, Martin Broerse <in...@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 <ja...@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 <au...@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/
>
>
Re: Whither CouchApps (Was: views failing due to
fabric_worker_timeout and OS process timed out)
Posted by Jan Lehnardt <ja...@apache.org>.
Hi Martin,
thanks for your comment.
> On 27 Feb 2017, at 07:52, Martin Broerse <in...@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 <ja...@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 <au...@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/
Re: Whither CouchApps (Was: views failing due to fabric_worker_timeout
and OS process timed out)
Posted by Martin Broerse <in...@martinbroerse.com>.
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
- Martin
On Sun, Feb 26, 2017 at 6:40 PM, Jan Lehnardt <ja...@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 <au...@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/
>
>