Re: [PROPOSAL] Officially deprecate CouchDB 1.x.

[Johs Ensby]

Roger that, 
over and out.
Johs

> On 8 Jul 2018, at 17:58, Jan Lehnardt  wrote:
> 
> There might be a misunderstanding of what is required to keep 1.x from being 
> deprecated.
> 
> It is not a detailed plan, lengthy discussion, or request for features or 
> extended support.
> 
> It is people spending the time in the code and issues to prepare branches 
> that they then produce release candidates of. The changes and issues triaged 
> can be bugfixes and security fixes.
> 
> Until the people who end up doing this, do not materialise, there is little 
> sense in further discussions, as merely making requests for work and not 
> putting in the work are a decent waste of everybody’s time.
> 
> Note how number of users/downloads/etc doesn’t factor into the above.
> 
> But while we are at it, from 75 responses to the CouchDB survey so far, we 
> have about 30% 1.x users. That’s down from ~70% in the 2017 survey (of 130 
> people). Note that multiple answers were possible, so the 1.x operators might 
> also run 2.x.
> 
> Those numbers and the trend along with everything else, I’m confident in 
> deprecating 1.x. 1.x is a fine piece of software and existing installations 
> of it will continue to run just fine, but this project is moving on.
> 
> Best
> Jan
> —
> 
>> On 8. Jul 2018, at 14:59, Johs Ensby  wrote:
>> 
>> Thanks Joan,
>> 
>> Your take on the data is
>>> To me the data is more proof that asking to keep 1.x on a lifeline is
>>> serving a vanishingly small amount of users.
>> 
>> 
>> I see no proof in the data and I disagree with respect how to best go about 
>> "serving a vanishingly small amount of users."
>> 
>> My take on the data is guesswork, but I would love to see someone tare it 
>> down with data:
>> 
>> 1) Millions have played with CouchDB (we are now left with a vanishingly 
>> small amount of these)
>> 2) Tens of thousands of servers are running with CouchDB today
>>   (20 000+ downloads of 2.x for Debian/Ubuntu/CebtOs/RHEL over a year 
>> indicate intention to upgrade, however, not actual upgrade)
>> 3) Average 100+/day downloads of 2.1.1 is another indicator of upgrade 
>> activity being strong.
>> 4) Thousands of sysops/sysdevs have CouchDB 1.x as part of their stack, they 
>> have not been heard in this discussion yet
>> 5) Regarding developer activity and experimentation, the spikes connected to 
>> releases are interesting:
>> -- 2,237 downloads of 1.7.1 for Windows on the same day early January is a 
>> significant spike that I don't know the background for.
>> -- Spikes for 2.x on Mac indicate 600-900 active Mac-using developers, but 
>> we don't know much about the sysops' plans to upgrade
>> 
>> Regarding my offer to write a paper to make a case for keeping 1.x open you 
>> said
>>>>> Thanks for the offer. Before writing up a full paper, what would
>>>>> your first 3 acts be?
>> I thought you wanted me to hold my horses and do this step by step
>> It would be a bit akward to start discussing the point 2-3 until having 
>> feeback on my intentions.
>> Should I proceed to point 1?
>> 
>> I still think your proposal, as it was "tabled" had been better without the 
>> first what-it-means-point, which is a far-reaching decision with unclear 
>> benefit.
>> Also, I think the result of the recent user survey should be published to 
>> support the decision making.
>> 
>> Johs
>> 
>> 
>>> On 7 Jul 2018, at 19:18, Joan Touzet  wrote:
>>> 
>>> Johs Ensby wrote:
>>>> Thanks for this, Joan
>>>> 
>>>> You must have put a lot time and effort into this and it is _highly
>>>> appreciated_.
>>> 
>>> You're welcome.
>>> 
>>>> The "official" https://www-us.apache.org/dyn/stats/couchdb.log seems
>>>> like a
>>>> nice place to follow the trend. 
>>> 
>>> For a limited amount of data, compared to how popular the binary
>>> distributions from bintray.com are, yes.
>>> 
>>> If Infra is able to give us access to the archived closer.lua data,
>>> we should be able to get a better picture of relative popularity,
>>> at least for people who click through https://couchdb.apache.org/ to
>>> download the tarball.
>>> 
>>>> What is in second column, download
>>>> time?
>>> 
>>> The script that generates the file is at:
>>> 
>>> https://svn.apache.org/viewvc/infrastructure/site/trunk/c

Re: [PROPOSAL] Officially deprecate CouchDB 1.x.

[Johs Ensby]

Thanks Joan,

Your take on the data is
> To me the data is more proof that asking to keep 1.x on a lifeline is
> serving a vanishingly small amount of users.


I see no proof in the data and I disagree with respect how to best go about 
"serving a vanishingly small amount of users."

My take on the data is guesswork, but I would love to see someone tare it down 
with data:

1) Millions have played with CouchDB (we are now left with a vanishingly small 
amount of these)
2) Tens of thousands of servers are running with CouchDB today
(20 000+ downloads of 2.x for Debian/Ubuntu/CebtOs/RHEL over a year 
indicate intention to upgrade, however, not actual upgrade)
3) Average 100+/day downloads of 2.1.1 is another indicator of upgrade activity 
being strong.
4) Thousands of sysops/sysdevs have CouchDB 1.x as part of their stack, they 
have not been heard in this discussion yet
5) Regarding developer activity and experimentation, the spikes connected to 
releases are interesting:
 -- 2,237 downloads of 1.7.1 for Windows on the same day early January is a 
significant spike that I don't know the background for.
 -- Spikes for 2.x on Mac indicate 600-900 active Mac-using developers, but we 
don't know much about the sysops' plans to upgrade

Regarding my offer to write a paper to make a case for keeping 1.x open you said
>>> Thanks for the offer. Before writing up a full paper, what would
>>> your first 3 acts be?
I thought you wanted me to hold my horses and do this step by step
It would be a bit akward to start discussing the point 2-3 until having feeback 
on my intentions.
Should I proceed to point 1?

I still think your proposal, as it was "tabled" had been better without the 
first what-it-means-point, which is a far-reaching decision with unclear 
benefit.
Also, I think the result of the recent user survey should be published to 
support the decision making.

Johs
 

> On 7 Jul 2018, at 19:18, Joan Touzet  wrote:
> 
> Johs Ensby wrote:
>> Thanks for this, Joan
>> 
>> You must have put a lot time and effort into this and it is _highly
>> appreciated_.
> 
> You're welcome.
> 
>> The "official" https://www-us.apache.org/dyn/stats/couchdb.log seems
>> like a
>> nice place to follow the trend. 
> 
> For a limited amount of data, compared to how popular the binary
> distributions from bintray.com are, yes.
> 
> If Infra is able to give us access to the archived closer.lua data,
> we should be able to get a better picture of relative popularity,
> at least for people who click through https://couchdb.apache.org/ to
> download the tarball.
> 
>> What is in second column, download
>> time?
> 
> The script that generates the file is at:
> 
> https://svn.apache.org/viewvc/infrastructure/site/trunk/content/dyn/closer.lua?view=markup
> 
> That field is generated on line 464, which is grabbing the final octet
> of the IP address for uniqueness. This can help de-duplicate data, or
> look for "ballot-stuffing" by someone trying to make one download or the
> other look more popular. ;)
> 
>> Although it is hard to compile totals out of this, the fact that the
>> numbers are
>> small is a fact. 
> 
> Again, compared to the binary downloads. Including the Docker downloads
> (which do not separate by version #, which is why I haven't included them
> in my email) there are 30+ million downloads of CouchDB in the wild.
> 
> To me the data is more proof that asking to keep 1.x on a lifeline is
> serving a vanishingly small amount of users.
> 
>> Lost of upside and few people to deal with as the
>> base,
>> which means that anyone who value CouchDB today can make a huge
>> impact, relatively speeking.
> 
> In terms of people making a large impact, it's more about the total
> number of contributors and committers to the project. As a PMC member,
> I want to see more contributors and committers who are interested in
> making CouchDB better, not in publicity hounds who just want to pad
> their resume by working on a high-profile OSS project. (Not pointing
> fingers at you, just thinking out loud.)
> 
>> Thanks also for this response:
>>> Thanks for the offer. Before writing up a full paper, what would
>>> your
>>> first 3 acts be?
>> 1) State my intentions, for feedback
>> 2) Table my case for a 1.x branch with limit scope, again for feeback
>> 3) Table an outline
> 
> In terms of 1.x scope, my first choice is to end support for it.
> Every single committer has voted +1 on this proposal so far; only you
> and one other dev have cast non-binding votes against it.
> 
> If there is sufficient interest to continue with 1.x, the primary
> need is for someone 

Re: [PROPOSAL] Officially deprecate CouchDB 1.x.

[Johs Ensby]

-1

A sunsetting discussion is very welcome, but this proposal is unclear,
based on week arguments and a lack of data, and as decision support
not the best of proposals.

1) To "table" a propoal for voting is problematic
---
Joan specifically reference "non-US" meaning of the "table", which means
"to begin consideration (or reconsideration) of a proposal". When listing
what this proposal means i 4 points, her point 1 is the premature "kill swtich".
It blocks any new or inactive developers from contributing.
A proposal that is "tabled" should be revised before voted on, or you run 
the risk that it is a pure developer-centric decision.

2) Lack of data
---
To use demand for support as a measure of usage can be misleading. 1.x
users face less problems, therefore they are the easiest to support. 
As a minimum, the results from the recent survey should be presented to 
verify the support for abanoning 1.x at this stage.
It would also be interesting to actively check the status of some hailmark 
installations like the npm Registry.

3) Lack of logic
---
The argument for dropping 1.x is that:
"No one is maintaining the 1.x.x branches..
By focusing [...] we can improve our release cadence"
This makes no sense. There are no resources to reallocate to 2.x "to push 
releases quickly out the door."

"avoid misleading our user base with false promises"
To my knowledge, no promises have been made and complaints aired.
Right now the couchdb github repo has 133 issues open 358 closed, 
11 of them have 1.x tag. (2 closed). That is 
All the 1.x tickets could be closed with a "known issues note" explaining
the decision to focus on 2.x issues. There are no red tag 1.x issues.

Conclusion
---
Tabeling a proposal that means:  "The Apache CouchDB project will no 
longer make new 1.x releases." is not tabeling at all. It is a far-reaching,
irreversible decision and to "sweethen" it with promises to endorce a new
team or a thousand forks is really backwards.
The discussion should be summed up in a final propsal whch is a less
drastic sunsetting proposal to avoid spreading uncertainty amoung users
and those that, while 2.x is still not bug-free, are making a forward-looking
decision on what DB system to choose.

Johs 

PS: 
all my opinions are IMHO, and I appreciate the efforts of the 2.x team
very much


> On 4 Jul 2018, at 22:51, Joan Touzet  wrote:
> 
> DISCLAIMER: This is a non-technical proposal to make a project decision.
> Per our Bylaws[1], this means that it should "normally be made with lazy
> consensus, or by the entire community using discussion-led
> consensus-building, and not through formal voting." However, since the
> intent is to make a significant policy change, this concrete proposal
> should be considered as a *lazy consensus* decision with a *7 day*
> timeframe (expiring on or about 2017-07-11, 23:59 UTC. Please give this
> thread your ample consideration.
> 
> 
> I would like to table[2] a proposal to terminate official Apache support
> for CouchDB 1.x. This means that:
> 
>  1. The Apache CouchDB project will no longer make new 1.x releases.
>  2. All remaining 1.x issues in JIRA and GH Issues will be closed.
>  3. Everyone can continue to use 1.x as long as they want.
>  4. People are welcome to continue discussing 1.x on the users@ list.
> 
> 
> The reason is simple: no one is maintaining the 1.x.x branches of
> CouchDB anymore. Issues stack up on the tracker[3] with no response.
> Original grand plans of back-porting 2.x features such as Mango to 1.x
> have not materialised. And when important security issues surface[4],
> having to patch 1.x as well as 2.x slows down the security team's
> ability to push releases quickly out the door.
> 
> By focusing on what we do best - supporting 2.x and beyond with bug
> fixes, new features, and ever-improving documentation and web UI - we
> can improve our release cadence and avoid misleading our user base
> with false promises.
> 
> 
> THAT SAID: There are two important footnotes to the proposal.
> 
> FIRST: If a group of interested maintainers start making active efforts
> to improve 1.x branch upkeep, I can speak with the full authority of the
> PMC to say that we'll endorse those efforts. But to un-mothball
> 1.x officially should require more than 1-2 people doing occasional
> bugfixing work. I'd personally want to see at least a 3-person team
> making sustained contributions to 1.x before re-activating official
> releases. Also, that work would need to be in-line with work currently
> happening on master; I wouldn't want to see new 1.x features materialise
> that don't have parallel

Re: On 1.x deprecation

[Johs Ensby]

OK:)


> On 6 Jul 2018, at 12:07, ermouth  wrote:
> 
>> Approximately how many 1.x nodes to you have in production now?
>> What is your estimated total no of users on these?
> 
> Sorry, can’t disclose this kind of info publicly.
> 
> All I can say I have zero nodes with 2.x in prod, despite we analyzed can
> we migrate several times. We can’t, 2.x just does not fit for production,
> which is well proved by Joan words about paid support requests, github
> issues and my own tests.
> 
> ermouth

Re: On 1.x deprecation

[Johs Ensby]

Thanks ermouth,

I agree with you that the logic behind the proposal could have been
clearer. A sunsetting announcement linked to the reliability criteria for 2.x
would have been preferable.

I value your opinions very much because I understand that you have
deployed large systems with CouchDB at the core.  If you would be so 
kind as to share numbers, answers to the following two questions would 
have been interesting.

Approximately how many 1.x nodes to you have in production now?
What is your estimated total no of users on these?

Johs


> On 6 Jul 2018, at 01:44, ermouth  wrote:
> 
> TLDR; Please vote -1 at @dev thread ‘[PROPOSAL] Officially deprecate
> CouchDB 1.x.’ All arguments of the proposal are of no basis.
> 
> ---
> 
> Hope, we all read deprecation statement from Joan. She provided one reason
> directly, also several were coined in indirect way.
> 
> 1. “No one is maintaining the 1.x.x branches of CouchDB anymore”
> 
> Probably that’s because they just do not need daily maintenance.
> 
> 2. “Issues stack up on the tracker with no response.”
> 
> Ok, lets count. Right now couchdb github repo has 133 issues open, 11 of
> them have 1.x tag.
> 
> 21 of those 133 are marked with red bug tag, but none of them with 1.x. So
> seems 1.x have no serious bugs, but 2.x have a pile.
> 
> How about “no response”? All 1.x issues have at least one. 33% of non-1.x
> issues have zero answers. So I’d say if there exist a stack up, it’s not
> related to 1.x, it’s more about 2.x.
> 
> 3. “Having to patch 1.x as well as 2.x slows down the security team's
> ability to push releases quickly out the door”
> 
> First, this game is two-sided. Probably, necessaty to fix not so adopted
> version slowed down the team from releasing very minor upgrade for very
> stable version widely used in production.
> 
> Probably, back-porting of not widely adopted 2.x features into 1.7 also
> slowed process down.
> 
> Or, probably, there were no slowdown at all? As I know, that ‘slow down’
> was never complained.
> 
> 4. “By focusing on what we do best - supporting 2.x”
> 
> As I showed earlier it’s looks incomparably easier to support 1.x than 2.x.
> As I can see from numbers, supporting 2.x issues have already taken all
> focus. It happened about 1.5 years ago I’d say.
> 
> Ok, have anyone ever complained? Today I consulted a guy from BY by phone,
> yesterday from IN – also privately. Classic reasonable CouchDB guys seem to
> be pretty well aware they won’t have a lot of help from official support
> anyway. They do not need bug fixes, they want to discuss use strategies,
> solution details, they want hints and opinions how to improve things that
> already works fine.
> 
> So 1.x doesn’t blur developers’ focus, unless developers start demnding
> granny’s blood. Granny is still pretty healthy.
> 
> 5. “I’m definitely seeing more people on 2.x these days than 1.x,
> *significantly* more - both from our informal support channels as well as
> through GitHub Issues and requests for paid support”
> 
> This argument is very strange. It looks like someone already have a lot of
> 2.x tickets and want even more. Sorry, but I don’t see how it reflects real
> users distribution, I only see that 2.x is more buggy and though sells paid
> support better.
> 
> ---
> 
> So, as I see all above arguments for deprecation have no relation to real
> accountable state of things, unless I suppose the goal is paid support.
> Honestly, I can’t believe in it.
> 
> Then why deprecate?
> 
> The deprecation notice by itself breaks reputation of 1.6/1.7, which is for
> now waaay more reliable than 2.x. At least 1.6 doesn’t bite unexpectedly.
> 
> I hope keeping things as is for about a year is well enough to fix most
> visible 2.x issues, and then – long live 1.x.
> 
> Unfortunately I’m not subscribed to @dev and can’t reply into past proposal
> thread even if get subscribed now.
> 
> So if you feel my arguments are reasonable, I ask you to cast ‘-1’ under
> that proposal. Thank you.
> 
> ermouth

………
Johannes Ensby


Business to Web AS
Tollbugata 8, N- 0152 Oslo, Norway
+47 611 00 006 (mobile)
+47 611 00 700 (switchboard)
j...@b2w.com
www.linkedin.com/in/ensby
www.b2w.com

Re: Call for "Must-fix" issues

[Johs Ensby]

Hi Harald,
how about starting a new thread on the topic, incuding dev@ and users@?
Compared to the https://db-engines.com/en/ranking_trend/system/CouchDB (auto 
collected web data)
the review service you linked to have a massive amount of reviews from MongoDB 
people.

Your question could motivate CouchDB users to summit reviews to g2crowd, and 
give detailed data in addition to the 44 people that did so already,
Johs:)

> On 5 Jul 2018, at 13:13, Harald Kisch  wrote:
> 
> Previously I got a lot of recognition by using CouchDB 1.x
> Now I would be interested in the reasons why people prefer Mongo, Cassandra, 
> Redis, HBase,..
> Is it the Quality of support only?
> https://www.g2crowd.com/categories/document-databases#highest_rated 
> 
> 
> harald
> 
>> Am 05.07.2018 um 12:57 schrieb ermouth :
>> 
>>> This is rather inaccurate
>>> A regrettable regression,
>>> but only a config issue
>> 
>> Well enough to block upgrade. Anyway, as we see now those non-technical
>> issues of different nature improve the number of requests for paid support.
>> I wouldn’t account this fact as popularity, as Joan did, however hope it at
>> least sweetens regrets.
>> 
>> ermouth
> 

Re: Call for "Must-fix" issues

[Johs Ensby]

>> 
>> Proxy authorization which is also in docs, but absent in 2.x.
> 
> it is not absent, just not exposed by default. You can configure to enable it 
> (it’s just not documented ;)

Hi Jan,
could you unveil this secret, please?
johs



> On 5 Jul 2018, at 10:53, Jan Lehnardt  wrote:
> 
> 
> 
>> On 5. Jul 2018, at 10:20, ermouth  wrote:
>> 
>> Proxy authorization which is also in docs, but absent in 2.x.
> 
> it is not absent, just not exposed by default. You can configure to enable it 
> (it’s just not documented ;)
> 
>> Single-node install without shards.
> 
> Both the /_setup_cluster endpoint and the Mac binaries already set q=1 & n = 
> 1 on setup. Everyone else can configure it.
> 
> Best
> Jan
> —
> 
>> 
>> ermouth
>> 
>> 2018-07-05 10:10 GMT+03:00 Johs Ensby :
>> 
>>> This thread reach out to CouchDB 1.x users to generate a list of
>>> "must-fix" issues that is preventing users to upgrade to the latest
>>> version of CouchDB.
>>> 
>>> It is in response to Joan's comment below regarding the
>>> non-technical proposal to make a project decision to terminate
>>> official Apache support for CouchDB 1.x.
>>> 
>>>> On 5 Jul 2018, at 06:31, Joan Touzet  wrote:
>>>> 
>>>> As for things in 2.x that are "must fix" before people can upgrade, I
>>>> too would like to see pull requests for those. Once again, your help is
>>>> most welcome in this - both in identifying a definitive list of those
>>>> must-fix issues, as well as code towards fixing them. If you'd like
>>>> to help with this important work, please start a new thread.
>>> 
>>> 
>>> 
>>> Mine is CouchDB as a proxy.
>>> The feature described here is not working in 2.1.1
>>> http://docs.couchdb.org/en/2.1.1/config/proxying.html?highlight=_proxy
>>> 
>>> Johs
>>> 
> 
> -- 
> Professional Support for Apache CouchDB:
> https://neighbourhood.ie/couchdb-support/
> 

………
Johannes Ensby


Business to Web AS
Tollbugata 8, N- 0152 Oslo, Norway
+47 611 00 006 (mobile)
+47 611 00 700 (switchboard)
j...@b2w.com
www.linkedin.com/in/ensby
www.b2w.com

Re: Call for "Must-fix" issues

[Johs Ensby]

Thanks,
what is the issue related to Single-node install without shards?
(I noticed that the convenience of one file on disk per database is gone, but 
is there anything else?)
Johs
 

> On 5 Jul 2018, at 10:50, ermouth  wrote:
> 
> Single-node install without shards.
> 
> ermouth
> 
> 2018-07-05 11:20 GMT+03:00 ermouth :
> 
>> Proxy authorization which is also in docs, but absent in 2.x.
>> 
>> ermouth
>> 
>> 2018-07-05 10:10 GMT+03:00 Johs Ensby :
>> 
>>> This thread reach out to CouchDB 1.x users to generate a list of
>>> "must-fix" issues that is preventing users to upgrade to the latest
>>> version of CouchDB.
>>> 
>>> It is in response to Joan's comment below regarding the
>>> non-technical proposal to make a project decision to terminate
>>> official Apache support for CouchDB 1.x.
>>> 
>>>> On 5 Jul 2018, at 06:31, Joan Touzet  wrote:
>>>> 
>>>> As for things in 2.x that are "must fix" before people can upgrade, I
>>>> too would like to see pull requests for those. Once again, your help is
>>>> most welcome in this - both in identifying a definitive list of those
>>>> must-fix issues, as well as code towards fixing them. If you'd like
>>>> to help with this important work, please start a new thread.
>>> 
>>> 
>>> 
>>> Mine is CouchDB as a proxy.
>>> The feature described here is not working in 2.1.1
>>> http://docs.couchdb.org/en/2.1.1/config/proxying.html?highlight=_proxy
>>> 
>>> Johs
>>> 
>> 
>> 

………
Johannes Ensby


Business to Web AS
Tollbugata 8, N- 0152 Oslo, Norway
+47 611 00 006 (mobile)
+47 611 00 700 (switchboard)
j...@b2w.com
www.linkedin.com/in/ensby
www.b2w.com

Call for "Must-fix" issues

[Johs Ensby]

This thread reach out to CouchDB 1.x users to generate a list of 
"must-fix" issues that is preventing users to upgrade to the latest 
version of CouchDB.

It is in response to Joan's comment below regarding the 
non-technical proposal to make a project decision to terminate 
official Apache support for CouchDB 1.x.  

> On 5 Jul 2018, at 06:31, Joan Touzet  wrote:
> 
> As for things in 2.x that are "must fix" before people can upgrade, I
> too would like to see pull requests for those. Once again, your help is
> most welcome in this - both in identifying a definitive list of those
> must-fix issues, as well as code towards fixing them. If you'd like
> to help with this important work, please start a new thread.



Mine is CouchDB as a proxy.
The feature described here is not working in 2.1.1
http://docs.couchdb.org/en/2.1.1/config/proxying.html?highlight=_proxy

Johs

Re: CloudWall 2.2

[Johs Ensby]

Congratulations Ermouth!

The number of systems and tools this replaces is "insane".
I found it hard to wrap my head around the previous version at first, but once 
in this works like a F-series Ford truck.

Johs

> On 4 Dec 2017, at 18:51, ermouth  wrote:
> 
> Hello all,
> 
> happy to announce CloudWall 2.2, http://cloudwall.me. It‘s a toy
> in-browser noBackend OS, which uses PouchDB/CouchDB instead of file system.
> 
> New features:
> * CW, both as a compiled design doc and as sources, now installs using
> replication.
> * All apps and documentation were upgraded.
> * Added latest Photon, Ddoc Lab and Inliner apps, with sources.
> 
> CW 2.2 can run a) from static hosting, b) as a couchapp bound to a
> dedicated domain, c) as a couch-hosted app, directly from index.html attach.
> 
> CloudWall is built by itself, so sources are good example how to build
> couch-hosted app of such complexity using nothing but browser.
> 
> ermouth

Re: Photon, 90% progress

[Johs Ensby]

Hi
>>its hidden potential is still nearly untouched, as I see it.
amen!

Fantastic job, ermouth!

johs

> On 15 Sep 2017, at 13:20, ermouth  wrote:
> 
> Thank you, Harald!
> 
> Actually, it‘s not a couchapp from thin air, Photon was created inside
> browser using couchapps. Photon never existed as source files, only source
> docs.
> 
> So entire couchapp (db hosted app) technology is powerful, its hidden
> potential is still nearly untouched, as I see it.
> 
> ermouth
> 
> 2017-09-15 11:41 GMT+03:00 Harald Kisch :
> 
>> Thank You, ermouth!
>> For me this is the best editor for CouchDB and the best way to edit large
>> JSON structures.
>> It is also the simplest way to install a CouchApp, simply by pasting your
>> JSON code into a design document and click save.
>> Photon also shows how powerful this kind of application is.
>> 
>> Great work!
>> 
>> harald
>> 
>> On Thu, Sep 14, 2017 at 10:14 PM, ermouth  wrote:
>> 
>>> Now 100% Futon features coverage. Recorded a screencast about Photon
>>> features https://www.youtube.com/watch?v=MHc6tozNhWU
>>> 
>>> ermouth
>>> 
>>> 2017-09-08 7:02 GMT+03:00 ermouth :
>>> 
 Think Photon is ready for more wide testing, https://github.com/
 ermouth/couch-photon
 
 As for now, 0.2.830, all original Futon features are covered, except
>> two:
 creating sync tasks and view compaction on per ddoc basis.
 
 Most original Futon features were bit improved in Photon. Also Photon
 includes several features not present in Futon, see boasting in PS.
 
 The sweetest new feature is instant update🌟. Right navbar button,
>> which
 opens About tab, now allows to check for updates from AWS S3 CDN (no
 logging there). It means Photon can be kept fresh in literally two
>>> clicks.
 
 Bug reports and suggestions are highly welcomed.
 
 ermouth
 
 PS. Photon boasting:
 
 * In-app tabs, restored on reload;
 * Valid state-to-URL# reflection, so most states have unique URLs;
 * Group actions for DBs and docs;
 * JSON for config, so group updates for config keys or even sections;
 * View navigation starting from a specific key;
 * You can choose to purge or retain doc content on deletion;
 * Doc revision navigation includes conflicts if any.
 
>>> 
>> 
>> 
>> 
>> --
>> --
>> 
>> Dipl.-Inf. Harald R. Kisch
>> 
>> Falkenstraße 19C
>> 81541 München
>> Germany
>> 
>> Mobil DE: +49 (0) 176 56 58 58 38
>> 
>> Skype: harald.kisch
>> Mail: haraldki...@gmail.com
>> 

Re: Fauxton, Futon and licensing obstacles

[Johs Ensby]

Hi,
I will post issues on github.
Will try to use it in a real situation to get a better feel, but post ideas on 
UI before I get too used to it.
(when I started using Cloudwall, I had a hard time getting my head around it, 
now I am used to it and feel no pain:)

This "DB browser" could potentially be an introduction to CouchDB for new people
Don't expect me to contribute much before the weekend comes.
j


> On 7 Sep 2017, at 16:35, ermouth  wrote:
> 
>> tabs sometimes dont respond to click
> 
> Yet unknown issue. Any additional details?
> 
>> numeric startkey not allowed
> 
> They are allowed actually: if you input a number, it‘s submitted as a
> number unless you add quot marks around it. What was the experience that
> made you think they are not allowed?
> 
>> codemirror box crops content
> 
> How this ‘crop’ looks like? Long lines are not wrapped and you can not
> scroll? Can you please provide more details.
> 
>> Missed direct access to attachments
> 
> It‘s just not yet coded. For now I think there will be narrow (~200px)
> right aside in the doc view. The aside will contain attachments navigation.
> 
>> I have opinions on UX, of course
> 
> Feel free to post suggestions to github )
> 
> ermouth

Re: Fauxton, Futon and licensing obstacles

[Johs Ensby]

Hi,
This lauches and works well in both 1.6 and 2.1 
a few things dicovered
tabs sometimes dont respond to click
numeric startkey not allowed
codemirror box crops content some times
Missed direct access to attachments

This looks very promising, concrats!
I have opinions on UX, of course, but don't know if/what kind of contribution 
you are looking for.
Any plans for updating bigbrother CW open source code, including this?

br
Johs


> On 6 Sep 2017, at 08:37, ermouth  wrote:
> 
> Progress so far: very early public beta
> https://github.com/ermouth/couch-photon
> 
> About 80% ready I hope, not tested in 2.x at all.
> 
> ermouth
> 
> 2017-08-30 21:45 GMT+03:00 ermouth :
> 
>> Work in progress, watch video https://youtu.be/lBVdIPZhDc4 to see current
>> state.
>> 
>> Right now codename Photon is a json with footprint well below 1.5Mb.
>> 
>> ermouth
>> 
>> 

Re: Fauxton, Futon and licensing obstacles

[Johs Ensby]

Great!
Can't wait to start using it
johs

> On 30 Aug 2017, at 20:45, ermouth  wrote:
> 
> Work in progress, watch video https://youtu.be/lBVdIPZhDc4 to see current
> state.
> 
> Right now codename Photon is a json with footprint well below 1.5Mb.
> 
> ermouth

Re: Fauxton, Futon and licensing obstacles

[Johs Ensby]

ermouth,
you are doing this as a cloudwell app with the cloudwall runtime supporting the 
single ddoc app, right?
Johs
> On 23 Aug 2017, at 21:56, ermouth  wrote:
> 
> Good idea, however I gonna start with CouchDB )
> 
> I‘ve recordered 5min screencast about JSON editor for CN Photon
> https://youtu.be/OQ_YJ0EZQjE
> 
> ermouth
> 
> 2017-08-23 9:10 GMT+03:00 Martin Broerse :
> 
>> Perhaps also include pouchdb databases in Photon. You would need to type
>> the database name you like to connect to because there is no index
>> implemented. See https://github.com/w3c/IndexedDB/issues/31 . Caching the
>> pouchdb database names would be be a nice feature for Photon. If Photo is
>> build in Ember we can use https://github.com/pouchdb-community/ember-pouch
>> to connect to the pouchdb databases.
>> 
>> On Tue, Aug 22, 2017 at 5:09 PM, ermouth  wrote:
>> 
>>> Several sketches http://jquerymy.com/kod/photon1.pdf
>>> 
>>> ermouth
>>> 
>>> 2017-08-20 15:07 GMT+03:00 ermouth :
>>> 
 Seems that Fauxton experiencing some troubles with React unfriendly
 licensing. It‘s a pity taking in account CouchDB 2 moved to fairly
>> stable
 state, and Fauxton itself received a lot of great improvements since
>> last
 year.
 
 However, in new circumstances, what do you think about re-creating
 something like Futon+ (for Couch 2) as a single ddoc? So you copy
 open-sourced ddoc json to any DB, run index.html attachment from the
>>> ddoc –
 and you‘re in.
 
 Basically, the idea is to re-create Futon-like app as a couchapp.
 
 If an idea is reasonable, is it reasonable to make the process openly
 funded in some way, to make it more rapid and controllable?
 
 ermouth
 
>>> 
>> 

Re: CouchDB 2.0 and "Intuitive HTTP/JSON API and designed for Reliability" for couchapps

[Johs Ensby]

Thanks er!
also for the exciting news:)
We gave up using 2.0 quickly and used 1.6 for the offline copy of the site we 
had on your 1.6 w rewrite as a function
Writing as lng list of rewrite rules to replace the router written w 
rewrite function
johs


> On 27 May 2017, at 07:23, ermouth  wrote:
> 
> Couch 2.0 fails to process rewritten paths with ampersands (more than 1
> param in query). Afaik (however I have not tested) this issue is fixed in
> 2.1.
> 
> Although I‘m not sure it is the reason.
> 
> To note: I plan to uncover a preview of new query server on Monday, as a
> full replacement for lists, shows, rewrites, updates and so on. With SMS,
> emails and all missing stuff. So stay tuned.
> 
> ermouth
> 
> 2017-05-23 13:47 GMT+03:00 Johs Ensby :
> 
>> Hi,
>> we have been using Couch 1.6 with a patch for the rewrite function, but I
>> wanted to see how 2.0 in single node mode was doing these past two days.
>> The test case was a rather big web site with a few databases holding a few
>> thousand documents, images, PDF attachments. It is performing very well on
>> Couch 1.6
>> 
>> Moving it from the cloud instance offline to a local Mac was as
>> straigthforward as replication can be and with a few tweeks to the
>> configration the site popped up on my iMac with all bells and whistles.
>> That is, a few records did not replicate from Couch 1.6 on Ubuntu/AWS to my
>> local Mac.
>> 
>> But what quickly turned out to be a bigger problem was that attachments
>> did not load into the browser reliably.
>> CSS files and images would sometimes load, somtimes not. Normally the CSS
>> files would load once and cache in the browser, but that did not prevent
>> pages from loaded occationally as if the css file was missing (not with a
>> 404, just show a red GET in the inspector without an error code).
>> I seem to remember that there was a discussion about Etags in 2.0, but
>> dont know if this is the issue here.
>> Strange things like the images coming up instead of the requested images
>> also happened.
>> Safari was a lot worse than Chrome.
>> 
>> Could anyone tell me if these are known bugs that are fixed in 2.1?
>> 
>> Best regards,
>> johs
>> 
>> 
>> 

CouchDB 2.0 and "Intuitive HTTP/JSON API and designed for Reliability" for couchapps

[Johs Ensby]

Hi,
we have been using Couch 1.6 with a patch for the rewrite function, but I 
wanted to see how 2.0 in single node mode was doing these past two days.
The test case was a rather big web site with a few databases holding a few 
thousand documents, images, PDF attachments. It is performing very well on 
Couch 1.6

Moving it from the cloud instance offline to a local Mac was as straigthforward 
as replication can be and with a few tweeks to the configration the site popped 
up on my iMac with all bells and whistles. That is, a few records did not 
replicate from Couch 1.6 on Ubuntu/AWS to my local Mac.

But what quickly turned out to be a bigger problem was that attachments did not 
load into the browser reliably. 
CSS files and images would sometimes load, somtimes not. Normally the CSS files 
would load once and cache in the browser, but that did not prevent pages from 
loaded occationally as if the css file was missing (not with a 404, just show a 
red GET in the inspector without an error code).
I seem to remember that there was a discussion about Etags in 2.0, but dont 
know if this is the issue here.
Strange things like the images coming up instead of the requested images also 
happened.
Safari was a lot worse than Chrome.

Could anyone tell me if these are known bugs that are fixed in 2.1?

Best regards,
johs

Re: Is this CouchApp mailing list active?

[Johs Ensby]

Hi Gustavio,
I can only answer as a member, but for me waiting for 1.7 is the reason for 
inactivity

br
Johs

> On 26. okt. 2016, at 20.05, Gustavo Delfino  wrote:
> 
> Hi all,
> 
> I noticed that the CouchApp ML is not mentioned in the mailing lists section 
> at http://couchdb.apache.org/
> Is this on purpose? My concern is about how people is going to learn about 
> his mailing list?
> 
> Additionally, on Erica's github homepage https://github.com/benoitc/erica and 
> also on the Python base CoachApp tool 
> (https://couchapp.readthedocs.io/en/latest/) there is information only about 
> a mailing list at http://groups.google.com/group/couchapp and I guess that it 
> is inactive as I sent a message a few days ago and never got a response.
> 
> Regards,
> 
> --
> Gustavo Delfino
> https://github.com/gdelfino
> 

Re: Couchapp experience in 2016

[Johs Ensby]

Jan,

The playful exploration of the single-tier functionality has followed CouchDB 
from the very start. It is one of the unique features, and even if you regard 
it as a side effect it has always held a great potential for creating interest 
and try-out activity for the project. 
Hence, it definately belong in the weekly news.

It goes without saying that this is IMO and all of that. I just dont to include 
the H because I dissaprove strongly of your respons to the massive work that 
ermouth has done to explore the limits of the so-called "coachapps":

To send signals of dissaprovment without giving a single reason is lazy and 
disrespectful, especially in this case given the quality and thoroughness of 
ermouth's work. To discourage couchapp contributions from the weekly news is 
extreme.
It is unworthy of an OS  project.

johs 

On 2. sep. 2016, at 08.27, Jan Lehnardt  wrote:

Project wise, we probably shouldn’t get people too excited about CouchApps at 
this point.


> On 2. sep. 2016, at 09.10, Jan Lehnardt  wrote:
> 
> 
>> On 02 Sep 2016, at 09:08, Alexander Shorin  wrote:
>> 
>> On Fri, Sep 2, 2016 at 9:53 AM, Jan Lehnardt  wrote:
 On 02 Sep 2016, at 08:45, Alexander Shorin  wrote:
 
 Still, it's about CouchDB use case with pro/cons described (;
>>> 
>>> sure, I just wouldn’t put it in the weekly news ;)
>> 
>> Why not? It's good, real experience that shows that better pick
>> node.js to get better performance rather than stay and dance around
>> couchapps which is fun. We don't have quite a lot of posts like that
>> kind.
>> 
> 
> I’m not inclined to explain my position on CouchApps yet again.
> 
> I’m not the editor in chief for the weekly news, but if asked, I would not 
> include this item for reasons that are reasonably well documented in the 
> mailing list archives (so not very).
> 
> Best
> Jan
> --
> 

Re: Couchapp experience in 2016

[Johs Ensby]

Awsome!
if couchapps was ever worth pursuing, you made the largest contribution to 
proving so.
johs

 
> On 2. sep. 2016, at 00.00, ermouth  wrote:
> 
> Tried out more or less pure couchapp approach in 2016 realities, I mean JS
> rewrites and PouchDB.
> 
> Written down a story about the project, from the couchapp side:
> http://lesorub.pro/how-it-works
> 
> It was interesting experience, couchapps still might be useful, in very
> rare cases )
> 
> ermouth

Re: Caching results of _list functions

[Johs Ensby]

Ermouth,
Congratulations with digging out hidden features of CouchDB!
I presume this works with new 2.0 and 1.7 and that these versions now have a 
new feature, Caching:)
johs

> On 26. mai 2016, at 22.17, ermouth  wrote:
> 
> Tested approach, works like a charm )
> 
> Surprisingly, it appears that approach is more suitable not for rendering
> pages, but for requests view->list, that respond with hundreds or thousands
> of small rows. In those cases I observe sometimes 2 orders of magnitude
> gain or even more, ie 300-500ms query server exec time turns into 3-5ms.
> 
> Even adding net latencies, that are around 100ms, gain is significant.
> 
> For page render, net latencies dim the gain, cause there is no visible
> difference between 100 and 150 ms lag at client side.
> 
> ermouth
> 
> 2016-05-19 11:41 GMT+03:00 ermouth :
> 
>>> - a function in a _list of a certain ddoc called directly via the _list
>> endpint
>> 
>> It‘s called via rewrite. Rewrite decides to call list. If rewrite already
>> have a result in cache and the result is not too old, rewrite sends results
>> directly.
>> 
>> If there is no result cached or it‘s too old, rewrite redirects to list.
>> And list, in turn, not only sends result, but caches it as well.
>> 
>>> - could you give us som sinppets
>> 
>> You make branch in ddoc, say .Cache, with code like:
>> 
>> (function(){
>> var cache = {};
>> exports.Cache = {
>>  get: function (key) {return cache[key]},
>>  put: function (key, val) {cache[key] = val;}
>> }
>> })();
>> 
>> In both rewrite and list to access cache you just use
>> 
>> var Cache = require ('Cache').Cache;
>> 
>> Now you can use it like Cache.get(key) and Cache.put(key, val) in rewrite
>> and list. Your cache will persist between requests until you change ddoc or
>> SM crashes.
>> 
>> 
>> ermouth
>> 
>> 2016-05-19 7:42 GMT+03:00 Johs Ensby :
>> 
>>> Hi Ermouth,
>>> this sounds like a bonus feature of significant value:)
>>> Together with the rewrite function this discovery would keep the couchapp
>>> enthusiasts of the community happy for a looong time, I believe.
>>> 
>>> If I understand you right,
>>> - a function in a _list of a certain ddoc called directly via the _list
>>> endpint (NOT via  _rewrite)
>>> - can cache a rendered result (e.g. a html page)
>>> - for a subsequent request via _rewrite (of the same ddoc) to pick up the
>>> cached result from RAM
>>> - using a timestamp inside that _rewrite function to compare against the
>>> timestamped name of the cached result to validate that the age is within a
>>> chosen tolerance
>>> 
>>> Following this 2-step approach (_list, then _rewrite)..
>>> - the _list function would have the full request context
>>> - while the _rewrite would have the limited request object available
>>> - the _rewrite and _list endpoints would need to be available
>>> 
>>> Control questions
>>> - does this mean that you cannot point a vhost to _rewrite and run all
>>> calls to _list via rewrite functions?
>>> - if you have one vhost pointing to _rewrite of a ddoc and another to
>>> e.g. _list would they still share the cache?
>>> 
>>> Testing this
>>> - could you give us som sinppets on how to test this, I would love to see
>>> this in action and test it towards my JS rewrite functions.
>>> 
>>> br
>>> johs
>>> 
>>> 
>>>> On 19. mai 2016, at 00.01, ermouth  wrote:
>>>> 
>>>> Since JS rewrites landed in 2.0, and I use JS rewrites heavily, I
>>> discover
>>>> some tricks with the new feature time to time. Despite I use patched
>>> 1.6.1
>>>> with js rewrites, tricks are suitable for at least single node 2.0 as
>>> well.
>>>> 
>>>> JS rewrites function runs in the context of a query server instance. QS
>>>> instance is a Spidermonkey process with 64Mb of RAM by default. It‘s
>>> single
>>>> threaded.
>>>> 
>>>> Actually, seems that all query server functions of one particular design
>>>> doc are executed inside one dedicated Spidermonkey instance. It means
>>> they
>>>> all share global context (also it means they share one thread).
>>>> 
>>>> Ddoc global context persists until Spidermonkey process is restarted. It
>>>> happens when SM instance crashes (runs out of RAM quota, unreco

Re: Post on Trigger

[Johs Ensby]

Hi Freddy,

you are pushing for a feature that I think would fall into a category that 
earlier discussions on this list pushed aside to a separate list, 
couchapp@couchdb.apache.org
I would asume it to be a ' "no-go" for design of philosophical reasons' as you 
put it based on these discussions.
However it can be done, I did it this way

-- the _rewrite interface of the new release let you define rewrite rules as 
javascripts functions (make your own API server if you like) 
http://docs.couchdb.org/en/1.6.1/api/ddoc/rewrites.html 

-- your own api can include calls to other endpoints 
http://docs.couchdb.org/en/1.6.1/config/http-handlers.html#global-http-handlers 

 and include thinks like the users IP address, user id etc 
-- OS Daemons http://docs.couchdb.org/en/1.6.1/config/externals.html 
 keep a node.js running 
in the background that can do anything you want
-- procedures or recipies for what to do, you can store as JSON in the database
-- these procedures can be promise chains that call your CouchDB several times 
to compose e.g. a report or perform a batch job, do things like extrenal 
content scraping or lookups before calling your message service to deliver the 
report nicely wrapped in a html template.
-- your triggers can be acted on by a daemon looking at _changes 
http://docs.couchdb.org/en/1.6.1/api/database/changes.html 
 

So this way you can customize the frontend and the backend to fit your needs. 
By making the node.js daemon very general and keeping all the variable stuff as 
JSON data, the node.js installation can go with your standard server image and 
you have your entire system on one platform, CouchDB, which is extremely 
convenient given its replication functionality.

br
johs

PS
I recommend this tool for design document programming: http://ddoc.me/ 



> On 19. mai 2016, at 13.49, Reddy B.  wrote:
> 
> Hi,
> 
> I am fairly new to CouchDb and loving it so far. I think this database is 
> shockingly underated. I love the "Relax" approach and the design choices  
> that have been done, and I hope things will continue with the same philosophy.
> 
> I couldn't find if this has been discussed before but I was thinking that it 
> would be extremely cool to be able to setup triggers that POST arbitrary json 
> to arbitrary endpoints. I think this would be a killer feature if there was 
> built-in support for that - and seems to fit well with the HTTP approach of 
> couch.
> 
> So basically, this would be about allowing us to add an arbitrary number of 
> triggers to any view. Each trigger would be called only if the view emitted 
> "something" and the trigger would receive the document passed as a parameter 
> to the view (this is to take advantage of the update frequency of views) Then 
> in terms of posting, there could be a new built-in javascript function 
> calling curl behind the scenes which can be called from the triggers.
> 
> For the same purpose, it would be interesting to introduce configuration 
> documents at the database level whose properties could be accessed from these 
> triggers (I'm thinking of situations when one would need to call a different 
> URL when in testing, staging, production etc...)
> 
> In terms of use case, this would allow us to do things as diverse as sending 
> email notifications, and maintenance tasks. More generally, this would 
> eliminate the need for most of the maintenance jobs out there while making 
> these systems much more efficient by removing the need to run jobs at 
> arbitrary times even when this is not necessary. Also, since most web 
> frameworks are asynchronous and process each request in a different thread,  
> this would be a way to easily parallelize certain operations. 
> 
> I just wanted to know if there was any chance to see this come out one day or 
> if this would be a "no-go" for design of philosophical reasons.
> 
> Cheers,
> 
> Reddy
> 

Re: Caching results of _list functions

[Johs Ensby]

Hi Ermouth,
this sounds like a bonus feature of significant value:)
Together with the rewrite function this discovery would keep the couchapp 
enthusiasts of the community happy for a looong time, I believe.

If I understand you right, 
- a function in a _list of a certain ddoc called directly via the _list endpint 
(NOT via  _rewrite)
- can cache a rendered result (e.g. a html page)
- for a subsequent request via _rewrite (of the same ddoc) to pick up the 
cached result from RAM
- using a timestamp inside that _rewrite function to compare against the 
timestamped name of the cached result to validate that the age is within a 
chosen tolerance

Following this 2-step approach (_list, then _rewrite)..
- the _list function would have the full request context
- while the _rewrite would have the limited request object available
- the _rewrite and _list endpoints would need to be available

Control questions
- does this mean that you cannot point a vhost to _rewrite and run all calls to 
_list via rewrite functions?
- if you have one vhost pointing to _rewrite of a ddoc and another to e.g. 
_list would they still share the cache?

Testing this
- could you give us som sinppets on how to test this, I would love to see this 
in action and test it towards my JS rewrite functions.
 
br
johs


> On 19. mai 2016, at 00.01, ermouth  wrote:
> 
> Since JS rewrites landed in 2.0, and I use JS rewrites heavily, I discover
> some tricks with the new feature time to time. Despite I use patched 1.6.1
> with js rewrites, tricks are suitable for at least single node 2.0 as well.
> 
> JS rewrites function runs in the context of a query server instance. QS
> instance is a Spidermonkey process with 64Mb of RAM by default. It‘s single
> threaded.
> 
> Actually, seems that all query server functions of one particular design
> doc are executed inside one dedicated Spidermonkey instance. It means they
> all share global context (also it means they share one thread).
> 
> Ddoc global context persists until Spidermonkey process is restarted. It
> happens when SM instance crashes (runs out of RAM quota, unrecoverable
> error happens etc), or when underlying design doc is changed.
> 
> It means _list function can cache results of rendering into RAM, and
> _rewrite function can later quickly respond with cached version, skipping
> redirect to heavy map/list. Cache container is just JS closure,
> instantiated/accessed using built-in require().
> 
> Unlike _list, JS rewrite function does not receive req.info, it would be
> too slow to tap DB on each request. It means we can not invalidate cache on
> local sequence change (DB update) – rewrite function just does not know DB
> was updated.
> 
> However we can use timestamp-based caching, even several seconds TTL of
> cache entries is enough to reduce average response time significantly (say,
> order of magnitude).
> 
> I‘ve tested approach a little and found it very promising.
> 
> Since this dirty hack is possible with _list fns only, without js rewrites,
> may be someone already employs it? Or at least tried?
> 
> ermouth

Re: login ui from a couchapp

[Johs Ensby]

Hi Nick,
kxepal would be better to give you details on the status of the new rewrite 
function, but to my best knowledge the code is to be found here:

https://github.com/apache/couchdb/pull/370 
<https://github.com/apache/couchdb/pull/370>
https://github.com/apache/couchdb-couch/pull/127 
<https://github.com/apache/couchdb-couch/pull/127>
https://github.com/apache/couchdb-chttpd/pull/96 
<https://github.com/apache/couchdb-chttpd/pull/96>
https://github.com/apache/couchdb-couch-mrview/pull/36 
<https://github.com/apache/couchdb-couch-mrview/pull/36>

Another discussion that you might be interested in if you want to use the couch 
web server directly and not behind a server is this discussion

http://mail-archives.apache.org/mod_mbox/couchdb-couchapp/201511.mbox/%3ccahw0xrtu8npjbr3%2bvvwysp5t2f%2by4w_zbdavpj_8bjnu4qd...@mail.gmail.com%3E
 
<http://mail-archives.apache.org/mod_mbox/couchdb-couchapp/201511.mbox/%3ccahw0xrtu8npjbr3+vvwysp5t2f+y4w_zbdavpj_8bjnu4qd...@mail.gmail.com%3E>

For now my workaround for multi request was to use a global handler to point to 
a small node.js query server that execute code stored in a couch db.
This way it's not problem to include multi request with promise chains etc as 
part of the routes in the new rewrite function, translate to the "backend" 
server the returns the composite content, or e.g. respons from a web service 
that you called or scraped content with some of your own data added and. The 
return can be served with your own html template.

I hear echoes from earlier discussions about couchapps in the back of my head 
now: So why this workaround to avoid a proxy in front?
The backend service is just one for all your servers/sites, totally generic 
since all the data reside in couch
This means that your systems can be replicated, all of it (apart from the web 
services attached of course), not just the data, e.g. if you want to use 
couchdb as a platform to deploy sites in one click
You can work in the incredibly well designed IDE for couch, Ddoc Lab, that you 
can find here http://ddoc.me/ <http://ddoc.me/>. This is awsome, dont be fooled 
by the clean UI. It replaces a lot of tools when you get into it, and it gives 
you a whole new perspective on "couchapps" ( I use the terms "Ddco lab", "couch 
site" and "design document" to avoid confusion).

johs

> On 16. apr. 2016, at 00.45, Nick  wrote:
> 
> On 15/04/16 16:29, Johs Ensby wrote:
>> Hi Nick,
>> the revolution comes with a new rewrite function (path list is not a static, 
>> but a function that can return path, status code, body, headers based on the 
>> request object en user environment. This enable you to make a router, 
>> firewall to allow jsut certain ip-range etc. 
>> 
>> The code was committed in November by Alexander Shorin  , 
>> but I don't know when to expect a release (1.7)
>> What I can say after testing it, is that it is a totally new world for 
>> couchapps
> 
> Thanks, sounds tantalising... are there any detailed specs?  Can't spot it 
> here:
> 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310780&version=12326160
> 
> In the mean time I assume that means the answer is "no change"?
> 
> 
> 
> 

Re: login ui from a couchapp

[Johs Ensby]

Hi Nick,
the revolution comes with a new rewrite function (path list is not a static, 
but a function that can return path, status code, body, headers based on the 
request object en user environment. This enable you to make a router, firewall 
to allow jsut certain ip-range etc. 

The code was committed in November by Alexander Shorin  , but 
I don't know when to expect a release (1.7)
What I can say after testing it, is that it is a totally new world for couchapps


johs


> On 15. apr. 2016, at 17.10, Nick  wrote:
> 
> I've been researching how one should secure a "couch-served app", in 
> particular allowing the user to log in but disallowing anonymous reads and 
> writes.
> 
> Seems like the most useful information I can find is five years old:
> 
> https://stackoverflow.com/questions/7389379/how-does-a-user-login-to-a-couchapp-that-has-a-reader-role-defined
> 
> Has there been any advance since then, or is a "welcome mat" DB still the 
> (only) way to do it within couchdb  without adding a proxy?
> 
> Cheers!
> 
> Nick
> 

Re: [PROPOSAL] Deprecate global functions in query server

[Johs Ensby]

Hi,
I dont know anything about the performance issues, but understand that require 
establish the object in memory once even referred to many times in a ddoc.
From a programmers view I would vote for "this", meaning that if it is a branch 
of the ddoc.
I remember that when I discovered that I could refer to my set of templates in 
a ddoc with this.templates[template] it was a big win.
As I know this today it can only work with refering to strings and that require 
must be used to parse function code into objects.
If what you are proposing is that loading the ddoc automatically parses code, I 
think this is a useful simplification.

johs



> On 2. des. 2015, at 21.03, Alexander Shorin  wrote:
> 
> On Wed, Dec 2, 2015 at 9:53 PM, ermouth  wrote:
>>> It is not possible to check how many arguments functions accepts?
>> 
>> It is, `var fn=function(x,y){};fn.length ==> 2`. Although, you not
>> necesserily write js function with all args. For example, I can define
>> update (doc), without req obj if I don‘t need it. Gist below uses only
>> first arg of 4 in validate_doc_update.
> 
> Hm...good point. Such JS feature ruins this use-case. Thanks!
> 
> So we have two candidates left:
> - require()
> - this
> 
> And seems like this is simpler both for users, developers and for
> implementation, since there is no need to hack require or inject
> special CommonJS lib in order to make things work.
> 
> --
> ,,,^..^,,,

Re: [PROPOSAL] Chainable requests

[Johs Ensby]

Ermouth,

> On 25. nov. 2015, at 18.18, ermouth  wrote:
> chunked response and reduce approach


I think both modes are valuable, conceptually we end up with 3 modes of respons
Technically it makes sense to describe as server response.

I am trying to think of how we want to spin this to the new developers

I would recommend that we name the feature as seen from the front-end developer

- single request 
- chained request
- progressive load

The 3rd being a variant of chained request not accumulating but spitting output 
into the client for as long as it takes

"Single reqest" is the normal thing, but what we see as one of the painful 
limitations of Couch
"Chained request" is the new thing that is not like multiple lines of code in a 
server side .asp php or node program, it is more like "ask for this, and 
depending on the answer, ask for this" like a "rewuest tree"
"Progressive load" is a super way to improve performance, it is writing for UX, 
"what the user needs right away is... then  and eventually she/he will be 
looking for .. if a link in the first chucks has been clicked yet"

johs

Re: [PROPOSAL] Chainable requests

[Johs Ensby]

http://jquerymy.com/kod/rewritelist.png 


> On 25. nov. 2015, at 21.08, Alexander Shorin  wrote:
> 
> Hi,
> 
> On Wed, Nov 25, 2015 at 8:18 PM, ermouth  wrote:
>> http://bit.ly/1NrTddP
> 
> URL seems broken: Unable to connect
> 
> --
> ,,,^..^,,,

Re: [PROPOSAL] Chainable requests

[Johs Ensby]

if this is low-hanging fruit, pick it!
I see no downside in implementing this, it removes a frustrating limitiation.

johs

> On 25. nov. 2015, at 18.18, ermouth  wrote:
> 
> 
> Implementation doesn‘t seem to be very difficult – only existing well known
> paradigms are used, nearly nothing new added.
> 
> Think I could try to implement it, my modest Erlang kung-fu should be
> enough for features described.

Re: serving html pages built from multiple lists or shows

[Johs Ensby]

Hi,
I have always used Handlebars serverside to do SEO-friendly pages
- a list that merges data and templates
- the doc type or other field decides what template to work
- used nested templates (sub teemplates for "modules" in the page" to assemble 
pages on the fly
- SEO agency of my clients get alle the snake oil inserted that they have sold 
as ways to improve page rank

the trick
- all templates in a templates folder (branch) of the design document
- refer to templates dynamically in the list of the design document as.. 

this.templates[doc.layout]

your entire template library is in memory after design document is loaded if I 
understand this correctly

johs

 

> On 19. nov. 2015, at 02.52, Giovanni Lenzi  wrote:
> 
> Hi Robin and Nick,
> You definitely CAN output full html, non js, SEO optimized web pages. We
> use that for our store index and apps pages (on
> https://www.smileupps.com/store).
> 
> We needed to:
> 1. create html templates of your pages with a templating library(we used
> handlebars.js),
> 2. precompile these templates before 'couchapp push' as server side
> javascript file in ddoc, such as lib/templates.js
> 3. create a view with name(path) of your page as key, emitting documents
> containing information of a same page under the same key. These elements
> may be html for header, links for navigation bar, markdown or raw html for
> your page content, a list of apps, or anything else
> 4. create a list which uses:
> - getrow() to fetch above elements in memory,
> - var tpls=require(lib/templates),
> - obtain html by merging templates and documents:
> htmlforheader=tpls.header(headerdocument),
> htmlfornavbar=tpls.navbar(linksdocuments)
> - return/output html from the list function
> 
> Probably the most difficult part is to precompile correctly those
> templates, in a way you can use them server side withouth issues. We used a
> node.js handlebar precompiler automatically run before 'couchapp push', but
> I think it should be possible to use  ermouth's ddoc.me to obtain the same
> result much more easily. Maybe he can speak for us..
> 
> Hope this helps,
> --Giovanni
> Il giorno 19/nov/2015 00:13, "Robin Millette"  ha
> scritto:
> 
>> Hi,
>> 
>> First time writing to this list, or any couchdb list for that matter.
>> Hope to see a brillant couchapp (the concept) revival in 2016!
>> 
>> On Wed, Nov 18, 2015 at 5:53 PM, Nick  wrote:
>> 
>>> Thanks - which indeed implies I am right and there is no solution that
>> works
>>> without JS on the client...
>> 
>> I also prefer to send complete html responses, for SEO and general
>> crawling benefits.
>> One strategy I used was to craft views to output different kinds of
>> rows. For instance, you've got you main content row, and you can also
>> have "block" rows, to pepper your html page with.
>> The list fonction can then handle those different row types and
>> generate proper html.
>> 
>> 
>> --
>> Robin
>> 

Re: serving html pages built from multiple lists or shows

[Johs Ensby]

Ermouth,
this is one of many extremely powerful features that is a bit hard to use the 
first time, and that eliminate a lot of not-so-smart workarounds.
If you could find the time to do a screen recording of what you just described, 
It would all be standard procedure from then on
johs)
> On 19. nov. 2015, at 05.17, ermouth  wrote:
> 
>> I think it should be possible to use  ermouth's ddoc.me to obtain the same
>> result much more easily. Maybe he can speak for us..
> 
> Since Ddoc Lab can post-process each item with individual code for an item,
> you can precompile your data in any suitable way before publishing. You can
> even keep you templates in external docs – Ddoc Lab is able to fetch
> externals before processing.
> 
> To have handlebars inside Ddoc Lab document, you should:
> 
>   - create any code snippet, it can be dummy
>   - mark it as having postprocessor
>   - put HB code into postprocessor and make pre-checker wrapper, which
>   will prevent HB init, if it was already initialized
> 
> Now each postprocessor have access to window.Handlebar. This approach is
> usefull for other libs also.
> 
> So to have your template precompiled, just write a template and
> postprocessor for it (think `return Handlebars.precompile(item.data)` –
> will be enough).
> 
> ermouth
> 
> 2015-11-19 4:52 GMT+03:00 Giovanni Lenzi :
> 
>> Hi Robin and Nick,
>> You definitely CAN output full html, non js, SEO optimized web pages. We
>> use that for our store index and apps pages (on
>> https://www.smileupps.com/store).
>> 
>> We needed to:
>> 1. create html templates of your pages with a templating library(we used
>> handlebars.js),
>> 2. precompile these templates before 'couchapp push' as server side
>> javascript file in ddoc, such as lib/templates.js
>> 3. create a view with name(path) of your page as key, emitting documents
>> containing information of a same page under the same key. These elements
>> may be html for header, links for navigation bar, markdown or raw html for
>> your page content, a list of apps, or anything else
>> 4. create a list which uses:
>> - getrow() to fetch above elements in memory,
>> - var tpls=require(lib/templates),
>> - obtain html by merging templates and documents:
>> htmlforheader=tpls.header(headerdocument),
>> htmlfornavbar=tpls.navbar(linksdocuments)
>> - return/output html from the list function
>> 
>> Probably the most difficult part is to precompile correctly those
>> templates, in a way you can use them server side withouth issues. We used a
>> node.js handlebar precompiler automatically run before 'couchapp push', but
>> I think it should be possible to use  ermouth's ddoc.me to obtain the same
>> result much more easily. Maybe he can speak for us..
>> 
>> Hope this helps,
>> --Giovanni
>> Il giorno 19/nov/2015 00:13, "Robin Millette"  ha
>> scritto:
>> 
>>> Hi,
>>> 
>>> First time writing to this list, or any couchdb list for that matter.
>>> Hope to see a brillant couchapp (the concept) revival in 2016!
>>> 
>>> On Wed, Nov 18, 2015 at 5:53 PM, Nick 
>> wrote:
>>> 
 Thanks - which indeed implies I am right and there is no solution that
>>> works
 without JS on the client...
>>> 
>>> I also prefer to send complete html responses, for SEO and general
>>> crawling benefits.
>>> One strategy I used was to craft views to output different kinds of
>>> rows. For instance, you've got you main content row, and you can also
>>> have "block" rows, to pepper your html page with.
>>> The list fonction can then handle those different row types and
>>> generate proper html.
>>> 
>>> 
>>> --
>>> Robin
>>> 
>> 

Re: Couch on port 80

[Johs Ensby]

not married to Ubuntu, but Gentoo seems like the wrong direction for me if this 
is true

Using/installing Ubuntu is like buying a car. It may have a few features you'll 
never need or use, and might need to have a couple features added as 
aftermarket parts. 
Using/installing Gentoo is like buying a pile of sheet metal, a few rubber 
trees, small pile of copper, a pile of sand, and an oil well. 

:D

> On 18. nov. 2015, at 23.18, Alexander Shorin  wrote:
> 
> On Thu, Nov 19, 2015 at 1:05 AM, Johs Ensby  wrote:
>> Couch-on-port-443-for-ubuntu recipe for dummies?
> 
> Sounds good. However, cannot help here since I'm on Gentoo P:
> 
> --
> ,,,^..^,,,

Re: Couch on port 80

[Johs Ensby]

Hey,

I think I should have started this tread as Couch on port 443
My goal: to have a linux server standard with ssl out of the box with no 
additional web server or app server.
The simplicity would mean a lot to lower threshold for server admin on 
platforms like DigitalOcean.
Fire up a DigitalOcean "snapshot", replicate some Couch buckets from the couch 
ecosystem, go!

I would like to pursue the below but am stuck due to close to zero linux brains
Anyone who have the brains and time to put together a 

Couch-on-port-443-for-ubuntu recipe for dummies?

johs
 

On Sun, Nov 15, 2015 at 10:01 AM, Johs Ensby mailto:j...@b2w.com>> wrote:
> Anyone with a better approach to this than this?
> 
> $ sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to 5984

Technically, you need to modify your init script to let it start
couchdb as root and then via chuid get it back running via couchdb
user, but I didn't try this way.

> I also tried an approach with Nginx forwarding everything to localhost:5984 
> with the new rewrite function.
> The problem here was that the IP adress of the request object got lost on its 
> way, so the new rewrite function would report
> peer to be 127.0.0.1

If your setup proxying right, then you'll have the following
directives in your conifg:

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

And then you can get peer IP address or real requested protocol via
these headers. General logic of headers processing is to look for X-*
headers first and then fallback to standard solutions.

Re: Couch on port 80

[Johs Ensby]

Thanks Alexander,
I am far from a linux geek, so I gave in to redirection with Nginx in front.
But I would love to see a full step by step recepie for running CouchDB on port 
80 on a server with no other systems than Ubuntu installed.
- A couch server as a minimalistic environment that was extremely simple to 
manage for new developers.

I think it is a good idea in terms fo making CouchDB the center of attention 
for a big crowd, not the little supporting role in the corner.
But is it technially a bad idea?

Johs

> On 17. nov. 2015, at 01.56, Alexander Shorin  wrote:
> 
> On Sun, Nov 15, 2015 at 10:01 AM, Johs Ensby  wrote:
>> Anyone with a better approach to this than this?
>> 
>> $ sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to 5984
> 
> Technically, you need to modify your init script to let it start
> couchdb as root and then via chuid get it back running via couchdb
> user, but I didn't try this way.
> 
>> I also tried an approach with Nginx forwarding everything to localhost:5984 
>> with the new rewrite function.
>> The problem here was that the IP adress of the request object got lost on 
>> its way, so the new rewrite function would report
>> peer to be 127.0.0.1
> 
> If your setup proxying right, then you'll have the following
> directives in your conifg:
> 
> proxy_set_header X-Real-IP $remote_addr;
> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
> proxy_set_header X-Forwarded-Proto $scheme;
> 
> And then you can get peer IP address or real requested protocol via
> these headers. General logic of headers processing is to look for X-*
> headers first and then fallback to standard solutions.
> 
> --
> ,,,^..^,,,

Re: "Couch-served app" vs. couchapp

[Johs Ensby]

Hi Bill,
I have been wrestling with the ideas of what an application in CouchDB is from 
the perspective of letting CouchDB be the center of integration in this article
https://medium.com/p/e39ac4397cea 

Like you say, there are so many scenarios where CouchDB is just a small piece 
in a large stack.
That is where we maybe should stop talking about couchapps and rather talk 
about design documents or "application server features"

Where applications in CouchDB really could become a strong concept is where you 
have it all in one design document or as I more an more think, in one database.
Up to now couchapps have been focused on pushing a set of resources into a 
design document.

If we start thinking of an application in CouchApp as a database with all you 
need, you have a new concept that is very powerful.
Ddoc Lab demonstrates this concept.
Deploy it as one design document is easy, but when it really becomes beautiful 
is where you see it this way:
- After you have deployed it, it is in a database that acts as a store for your 
ddoc source files. No longer files on your disk, you now have an IDE online 
that travels with your sources files, lets call it your "lab"
- You tweak the rewrite of a design document that extends Ddoc Lab and you have 
an even better IDE.
- Let it sit there in an empty database and every time you start a big project, 
you just replicate this.

Your application is a database set up for a software project. Every time you 
start a new project, you replicate the "original" database.
It is a one-line or on-line installation of apps and storage.

If you have put a lot of work into a server in AWS, you store in an AMI and if 
you do the same on DigitalOcean you store it as a Snapshot.
This is the same thing.

click and go, no setup , no installation, it is so easy and super quick to 
launch an application or set of applications with its data storage in one go.
It is the same as AMI and Snapshot, but at a lower level.

I am still looking for the good term. 
Maybe it is less focused on the app and more on the system.
Maybe I will start thinking of it as a server inside the CouchDB instance.
Couch system, it's not a "living room", but is is a "apps syncs with your data" 
concept.
The border between app and data blurs as the apps themselves are JSON documents 
with attachments for the client to load.

We could call it  AppBase or Application Bucket.
Compared to a normal bucket or database, this has apps in it.

Let me give you an example.
The first time I installed Ddoc Lab, i cut and paste into Futon/Fauxton.
It takes ages to store, Fauxton even sends conflicting messages while storing.
The next time, I just replicate the App Bucket. It takes a second.
Imaging creating a system ofEden apps that takes a day to install, as a App 
Bucket, you can share it in a second or five. Across the world.
This is the market place we need.

Johs


> On 16. nov. 2015, at 19.58, William Edney  wrote:
> 
> Thanks everyone for the feedback.
> 
> It was good to think about Johs comment that there also tends to be
> server-side document that define the server-side processing. We have so
> little of that in our current demos of our product that I hadn't considered
> it (the vast majority of action in our product happens in the client).
> 
> Martin - given that our tools are sort-of purpose built for our product, it
> might not be convenient to use them with other JS frameworks. You'd have to
> mess around with the directory structure - it might be possible.
> 
> Our stuff will be available under an Open Source license. Note that the
> Couch stuff is only one (small) piece of an overall larger, full stack
> framework. We'll have a lot more to say in the next few weeks :-).
> 
> Cheers,
> 
> - Bill
> 
> 
> On Sun, Nov 15, 2015 at 1:22 PM, Johs. E  wrote:
> 
>> Hi Bill,
>> I think your “couch-served apps” is a good candidate for a term to could
>> adopt as replacement for couchapps.
>> 
>> I  use "applications in CouchDB" rather than Couchapps.
>> An application in CouchDB to me is one or more design documents that
>> define the server side processing as well as define what modules to load
>> client side.
>> 
>> johs
>> "
>>> On 15 Nov 2015, at 17:40, William Edney 
>> wrote:
>>> 
>>> I know there are other products out there that do similar things to ours.
>>> Does the term 'Couch-served app' make sense to folks and should we be
>> using
>>> it this broader context or does someone have a better suggestion?
>> 
>> 

Re: Meet copy-couch!

[Johs Ensby]

Hi Martin,
I have left couchapp, the builder, for Ddoc Lab (ddoc.me <http://ddoc.me/>) for 
good.
ermouth has announced that gihub/folder support import/export is on his roadmap 
for Ddoc Lab, also.
Johs)

> On 15. nov. 2015, at 09.12, Martin Broerse  wrote:
> 
> Hi Johs,
> 
> Is seems you don't get version 1.0.1 or 1.0,0 but 0.8.3 See
> https://launchpad.net/~couchapp/+archive/ubuntu/couchapp
> 
> If you are on Ubuntu perhaps you can create 1.0.1 for now?
> 
> - Martin
> 
> 
> -- Forwarded message --
> From: Martin Broerse 
> Date: Sun, Nov 15, 2015 at 8:28 AM
> Subject: Re: Meet copy-couch!
> To: Johs Ensby 
> Cc: couchapp@couchdb.apache.org
> 
> 
> Johs,
> 
> No I was refering to this:
> 
> http://couchapp.readthedocs.org/en/latest/couchapp/install.html#installing-on-ubuntu
> 
> I use Windows and are not an Ubuntu user, I compiled the last stable
> couchapp release 1.0.1 from  2011 for Windows. See:
> https://github.com/couchapp/couchapp/releases
> 
> What stable version do you get with ppa:couchdb/stable ? The 1.0.1 version?
> 
> -  Martin
> 
> On Sun, Nov 15, 2015 at 8:04 AM, Johs Ensby  wrote:
> 
>> Martin,
>> are you looking for this?
>> 
>> $ sudo add-apt-repository ppa:couchdb/stable -y
>> 
>> johs
>> 
>> 
>>> On 15. nov. 2015, at 07.59, Martin Broerse 
>> wrote:
>>> 
>>> Next up? If you are in the vibe perhaps couchapp 1.1.0-beta.1 ;-). We
>> need
>>> to find someone who can create a PPA for ubuntu. I will compile the
>> windows
>>> version and couchapp is back from 2011 to 2015.
>>> 
>>> - Martin
>>> 
>>> On Sun, Nov 15, 2015 at 4:57 AM, Benjamin Young 
>>> wrote:
>>> 
>>>> https://github.com/bigbluehat/copy-couch
>>>> 
>>>> Finally whipped up my little backup script. It's intentionally stupid,
>> but
>>>> with a few more tweaks could cover several different scenarios for
>> making
>>>> copies of couches. :)
>>>> 
>>>> Given a properly configured config.ini file, it will take all the
>> couch's
>>>> from one CouchDB and store them as `backup/{local CouchDB instance's
>>>> UUID}/{db name}` (plan is to make this configurable).
>>>> 
>>>> This means that you could use a single CouchDB in the Sky (or cloud or
>>>> whatever) to copy your various local CouchDB instances into without
>>>> conflict.
>>>> 
>>>> Now, these aren't (yet) "true" rolling backups or anything. They're just
>>>> "cloud copies" (assuming that architecture) of local databases. It's
>>>> helpful when (as I have had happen), your computer dies and all those
>> local
>>>> dev couch's are gone. T_T Saves a few tears, anyhow.
>>>> 
>>>> Next up?
>>>> Configurable _replicate or _replicator endpoint.
>>>> Configurable database names!
>>>> A copy.py script that takes one DB and replicates it to another.
>>>> Anything else? :)
>>>> 
>>>> Thanks for listening. ^_^
>>>> Benjamin
>>>> --
>>>> http://bigbluehat.com/
>>>> 
>> 
>> 

Re: Meet copy-couch!

[Johs Ensby]

Martin,
are you looking for this?

$ sudo add-apt-repository ppa:couchdb/stable -y

johs


> On 15. nov. 2015, at 07.59, Martin Broerse  wrote:
> 
> Next up? If you are in the vibe perhaps couchapp 1.1.0-beta.1 ;-). We need
> to find someone who can create a PPA for ubuntu. I will compile the windows
> version and couchapp is back from 2011 to 2015.
> 
> - Martin
> 
> On Sun, Nov 15, 2015 at 4:57 AM, Benjamin Young 
> wrote:
> 
>> https://github.com/bigbluehat/copy-couch
>> 
>> Finally whipped up my little backup script. It's intentionally stupid, but
>> with a few more tweaks could cover several different scenarios for making
>> copies of couches. :)
>> 
>> Given a properly configured config.ini file, it will take all the couch's
>> from one CouchDB and store them as `backup/{local CouchDB instance's
>> UUID}/{db name}` (plan is to make this configurable).
>> 
>> This means that you could use a single CouchDB in the Sky (or cloud or
>> whatever) to copy your various local CouchDB instances into without
>> conflict.
>> 
>> Now, these aren't (yet) "true" rolling backups or anything. They're just
>> "cloud copies" (assuming that architecture) of local databases. It's
>> helpful when (as I have had happen), your computer dies and all those local
>> dev couch's are gone. T_T Saves a few tears, anyhow.
>> 
>> Next up?
>> Configurable _replicate or _replicator endpoint.
>> Configurable database names!
>> A copy.py script that takes one DB and replicates it to another.
>> Anything else? :)
>> 
>> Thanks for listening. ^_^
>> Benjamin
>> --
>> http://bigbluehat.com/
>> 

Couch on port 80

[Johs Ensby]

Hi,

Setting up servers with Couch as the web server, I have used firewall 
prerouting to redirect everything port 80 to couch
Anyone with a better approach to this than this?

$ sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to 5984

I also tried an approach with Nginx forwarding everything to localhost:5984 
with the new rewrite function.
The problem here was that the IP adress of the request object got lost on its 
way, so the new rewrite function would report 
peer to be 127.0.0.1
while the first method leaves the request object raw and wil enable us to do 
all sorts of IP address range stuff in the rewrite.


johs


PS
for those not familiar with the beuty of combining
- couch on port 80 and
- vhost to _rewrite og a design document...

This combination allows design documents that act as API servers (very exiting 
with the new rewrite function) and be endpoints of various domains.
On the same Couch instance, you can effectively do hosting service for many 
small sites. The convenience of managing this service through over REST opens 
up for some exiting concepts. Pointing to multiple design documents in the same 
database or multiple design documents in multiple databases.

With ermouth's round robin technique inside the new rewrite function, we will 
also be able to create enough load balancing inside Couch to overcome some of 
its weekness at this point.

Balancing load between several design documents as trick to multiply the 
request per second capacity for Couch 1.7 could be combined with using IP 
address range to prioritize "home market" towards the rest of the world, and 
send requests from regions in the world outside a site's market to a login page 
or "the contene is not available for you region" page. 

If you are e.g. a dentist or thousand devices in a local village, there is 
really no need to serve the entire internet with anything, especially if you 
are running on a tiny linux machine inside a small box some sort that cannot 
hold the entire stack of systems that the couchapp haters think we should 
install.

Re: Ecosystem around CouchDB applications

[Johs Ensby]

Hi all,

I have written an article on AWS vs DigitalOcean, trying to figure out what is 
the best platform for a CouchDB based hosting service
https://medium.com/p/b7b320fb6bae <https://medium.com/p/b7b320fb6bae>

and updated the article about the
ecosystem pilot project <https://medium.com/@ensby/e39ac4397cea>

Johs

> On 9. nov. 2015, at 11.19, Johs Ensby  wrote:
> 
> Hi All,
> 
> I have written the followup Applications in CouchDB article
> I am afraid this will be a 10+ minute read, I had to establish a vocabulary 
> to get to what I propose
> https://medium.com/@ensby/a-possible-couchdb-application-ecosystem-e39ac4397cea
>  
> <https://medium.com/@ensby/a-possible-couchdb-application-ecosystem-e39ac4397cea>
> 
> 
> The first article is here
>  to the https://medium.com/@ensby/applications-in-couchdb-946a9c19015 
> <https://medium.com/@ensby/applications-in-couchdb-946a9c19015>
> 
> Thanks for the comments on the first article.
> 
> Johs

Re: Simple Things

[Johs Ensby]

Benjamin,
I really like your approach:)
Taking the small everyday things and putting them properly on Github.
It could become a great collection for starters.

Johs

> On 15. nov. 2015, at 04.42, Benjamin Young  wrote:
> 
> Agreed, johs!
> 
> Personally, I'm beginning to work hard at taking these rocks out of my own 
> shoes and tossing code up as I have it (or finding the old bits of junk I've 
> done and pushing them online). I'll be sending in a couple of those shortly, 
> in fact. :)
> 
> -Original Message-
> From: Johs Ensby [mailto:j...@b2w.com] 
> Sent: Friday, November 13, 2015 11:56 AM
> To: couchapp@couchdb.apache.org
> Subject: Re: Simple Things
> 
> Benjamin,
> I too think that what is missing is to reveil more of the simplicity of Couch 
> with some super simple tools.
> The problem my be that what is needed is too simple for developers to bother 
> put in online.
> Make a list, and I think this thread migth surprise you:) Let's celebrate 
> simplicity
> 
> johs
> 
> 
>> On 13. nov. 2015, at 15.29, Benjamin Young  wrote:
>> 
>> JSON (as you're all too well aware) doesn't support line breaks. 
>> Consequently, one of the major pain points when working with JS in 
>> JSON is escaping it to line breaks. Futon didn't do this. Fauxton 
>> still doesn't do this. Neither of them have editors for "updates" or 
>> "shows" or anything else CouchApp related. Ddoc.me <http://ddoc.me/> 
>> (as mentioned) is fab for an "all in" environment, but I literally 
>> just want a copy/paste JS to "\n" escaped, JSON friendly field. :-P 
>> That's it. ;)
> 

Re: Simple Things

[Johs Ensby]

Benjamin,
I too think that what is missing is to reveil more of the simplicity of Couch 
with some super simple tools.
The problem my be that what is needed is too simple for developers to bother 
put in online.
Make a list, and I think this thread migth surprise you:)
Let's celebrate simplicity

johs


> On 13. nov. 2015, at 15.29, Benjamin Young  wrote:
> 
> JSON (as you're all too well aware) doesn't support line breaks. 
> Consequently, one of the major pain points when working with JS in JSON is 
> escaping it to line breaks. Futon didn't do this. Fauxton still doesn't do 
> this. Neither of them have editors for "updates" or "shows" or anything else 
> CouchApp related. Ddoc.me  (as mentioned) is fab for an "all 
> in" environment, but I literally just want a copy/paste JS to "\n" escaped, 
> JSON friendly field. :-P That's it. ;)

Re: Siri integration with CouchDB 1.7.0

[Johs Ensby]

Thanks for the tip, ermouth
this is nicer than siri for my purpose:)
Johs

> On 13. nov. 2015, at 10.42, ermouth  wrote:
> 
> I‘ve tried to emit https://www.talater.com/annyang/ into CloudWall – got a
> lot of fun :)
> 
> But all these solutions generate significant traffic all the time mic is
> on.
> 
> ermouth

Re: Siri integration with CouchDB 1.7.0

[Johs Ensby]

:), Alexander,
> 
> Off: "Ok, Couch, get document 05246732d4a48fb4dbc4b967472a665f from
> database bar" (:
> 
> --
> ,,,^..^,,,



With "website xyz" being an entry in my address book along with others with the 
first name "website" Siri sends a mail to an account with e.g. Postmark which 
provide parsing to a webhook on my couchDB site.
Rewrite as a function will allow us to make nice APIs for webhooks, combining 
the request object with transforming simple GET's to complex POSTs and some 
COuch core features will make great demos. 

Sitting in a client meeting where we just finished going through the staging 
version of a web site I would press Siri

Siri: ding-ding
Me: "email website"
Siri: "Which website"
Me: "xyz"
Siri: "What's the subject of the email?"
Me:"Go live"
Siri: "What would you like your email to say?"
Me:"Go live now"
Siri: OK, here is your email message to website xyz, would you like to send it?"
Me:"yes"
Siri: "OK, I'll send it"

The site is replicated and we go to the url of the live site, voala.
Stupid, as click a button would be easier of course, but this is very doable 
and the client's question would be "What on earth is that technology you are 
using?"
And I say, it's version 1.7.0
Client: Version of what?


Me: CouchDB
It can do a lot of things, just go to the site that we set up for your asian 
market, it is on our Singapore data center, completly independant of your 
european site which is hosted in Ireland, just go to asia.xyz
Client: But this is not updated!
Me: let me fix that, (pressing Siri)

Siri: ding-ding
Me: "email website"
Siri: "Which website"
Me: "xyz"
Siri: "What's the subject of the email"
Me:"Go live"
Siri: "What would you like your email to say"
Me:"Go live in asia"
Siri: OK, here is your email message to website xyz, would you like to send it?"
Me:"yes"
Siri: "OK, I'll send it"

Me to the Client: refresh your browser now

The client: "Nice, eh.. you know what, we have a big project coming up about 
our strategy on the internet of things and I am going to make a presentation to 
the CEO next week, could we lunch now and have a chat to see if there is 
anything for you guys in that project? Maybe you could come up with ideas for 
some pilot projects, prototypes, you know, this is really important for us and 
my CEO is preparing a presentation to our board..."

I am just trying to think of a nice script for the 1.7.0. launch video:).

johs

Siri integration with CouchDB 1.7.0

[Johs Ensby]

Hi,
has anyone any experience with integrating Siri voice control with CouchDB?

Since Siri is an interface that Apple is still controlling tightly, the 
workarounds that I know of are
send message
send mail
enter calendar event/reminder

E.g. by entering calendar events, you could via calendar integration and 
subscription eventually post data to Couch
Same thing with sms mail, set up an account that forwards messages to couch

With rewrite as a function, it will be easy to create an API for incoming data 
that do some pattern matching on the fly and store clean data coming from Siri 
with not special app on the iPhone.

Anyone here that have been on to things like this or know of apps use Siri as 
input and output REST requests?

johs

Re: CouchDB 1.7.0 Roadmap

[Johs Ensby]

Welcome to CouchDB,  Oskar and Peter,
It would be great to see you on couchapp@couchdb.apache.org 
 where you will find a lot of 1.7 fans

To Peter; hope you can find some CouchDB enthusiasts in Stockholm !
Johs from Norway:)

> On 12. nov. 2015, at 21.31, Oskar Maria Grande  wrote:
> 
> Hi awesome CouchDB folks,
> 
> my friend Peter and I would very much enjoy evaluating the mentioned auth 
> topics, JWT is especially intriguing to us.
> 
>> May be we can also include else experimental features, like JWT and/or
>> Delegated auth. Personally, I would like to see them, but it's all up
>> to you Klaus and Jan (;
> 
> Peter is studying at Stockholm University and we hope to be able to use an 
> interesting (security as well as Erlang related) topic for his thesis and 
> maybe to work on together in general :)
> 
> Suffice to say we’ve both been huge CouchDB fans and this would mean quite a 
> lot to us in terms of finally getting our hands dirty with Couch internals!
> 
> Any personal 2c would be very much welcome!
> 
> Thanks and cheers from Vienna,
> 
> Oskar & Peter
> 
> # Oskar Maria Grande | @musha68k
> # http://daruma.io
> # +43 676 955 3646
> 
>> On 12 Nov 2015, at 16:05, Alexander Shorin  wrote:
>> 
>> Dear CouchDB team,
>> 
>> While we're all working on 2.0 is in progress, I fear that we'll end
>> this year without a single release. Technically, there is only one
>> month left till 2016 excluding holidays, but let's be honest - that's
>> not enough for 2.0. So I propose the plan for 1.7 release to not end
>> this year with empty list.
>> 
>> There are a couple of important changes that we have for it and users
>> are waiting for. Primary is the Erlang 18 compatibility, but not only.
>> 
>> What we already have on 1.x.x branch:
>> 
>> - COUCHDB-1011: replicate by document ids from futon
>> - COUCHDB-1275: decode database names in recent used list
>> - COUCHDB-2225 Enforce that shared libraries can be built by the system
>> - COUCHDB-2430: Disable Nagle's algorithm
>> - COUCHDB-2583: fix connection dropping by the resources which doesn't
>> require any payload
>> - COUCHDB-2761: Support glibc >= 2.20
>> - COUCHDB-2783: Bind both to IPv4 and IPv6
>> - Futon: Fixed potential XSS issue in jquery.ui
>> - jquery.couch: Fixed document copying
>> - sslv3 support is deprecated
>> - Support for user configurable SSL ciphers
>> - Multiple minor documentation fixes
>> - Support Erlang 18
>> 
>> What we can backport without worry:
>> 
>> - COUCHDB-1356: Return username on POST to /_session
>> - COUCHDB-1447: X-Couch-* headers missed if custom headers were returned
>> - COUCHDB-1964: eunit test suite
>> - COUCHDB-2310: /db/_bulk_get
>> - COUCHDB-2375: Respond with HTTP 400 Bad Request on invalid revision number
>> - COUCHDB-2534: db security should respect authed users
>> - COUCHDB-2732: Use thread local storage for couch_ejson_compare NIF
>> - COUCHDB-2752: Validate Host header
>> - COUCHDB-2873: Update snappy to 1.1.3
>> - Multiple improvements that we have for replicator
>> 
>> What I would like to add:
>> 
>> - COUCHDB-2722: Keys from rewrited query params should be blank when
>> not specified in the URI
>> - COUCHDB-2874: Rewrites via query server
>> - COUCHDB-2877: Return nicer error for bad Authorization header
>> - Deprecation of /_log
>> - Deprecation of OAuth auth
>> - Enable CORS by default:
>> https://fetch.spec.whatwg.org/#basic-safe-cors-protocol-setup
>> - Remove Fauxton - AFAIK, it supports 1.x no more and current version
>> in 1.x.x branch is heavily outdated.
>> - Mark this release as LTS with short (really) cycle of bug fixes ship
>> 
>> Questionalbe:
>> - Add systemd notification support.
>> 
>> May be we can also include else experimental features, like JWT and/or
>> Delegated auth. Personally, I would like to see them, but it's all up
>> to you Klaus and Jan (;
>> 
>> But even without these experimental features, we have quite long list
>> of changes to ship.
>> 
>> The plan is simple: for November get all from backport and add lists
>> into 1.x.x branch and ship 1.7 in first half of December. Quite good
>> Christmas Eve present for everyone. Personal deadlines 30th November
>> and 20th December respectively.
>> 
>> Since "everyone is busy on 2.0" I'll take care of this.
>> 
>> P.S. If someone has else important bugfixes on mind to include, please
>> drop a notice. For 2.0 we have ETOOMANY useful changes, but I would
>> like to stop only on really important ones. Like replicator ones as I
>> mentioned.
>> 
>> --
>> ,,,^..^,,,
>> 
> 

Fwd: CouchDB 1.7.0 Roadmap

[Johs Ensby]

May the force be with you!
Johs


> Begin forwarded message:
> 
> Since "everyone is busy on 2.0" I'll take care of this.

Re: Ecosystem around CouchDB applications

[Johs Ensby]

Hi Tim
I am with you on the freedom, recommend goes a long way if you think you have 
spotted a winner.
Vue looks like one for the new developers, but jQueryMy is technically better 
in a JSON world.

Johs

> On 10. nov. 2015, at 16.23, Tim Black  wrote:
> 
> On 11/10/2015 01:14 AM, Johs Ensby wrote:
>> About javascript framework I have a dilemma, go for ermouth's jQueryMy which 
>> is extremely efficient and has the beauty of easy integration for widgets 
>> into Inliner (actually you can have a dynamic view of widgets pop up in 
>> Inliner and as easy to include as adding and cropping an image. 
>> My other alternative is to use Vue.js as I have the feeling that it will 
>> suit the simplicity goal.
>> I would appreciate advice.
> I'm inclined to say you should recommend, but not require, one
> JavaScript framework.  That technology changes so quickly, and people
> want freedom to choose their own framework.
> 
> Tim
> 

Re: Ecosystem around CouchDB applications

[Johs Ensby]

Hi All,

thanks for all the comments to the Medium article.
I have updated the Pilot project after very useful comments from Giovanni.

The ecosystem pilot project sketch now identifies
10 possible specialized roles in the ecosystem
10 transaction points for revenue sharing
5 of these collecting money from sub suppliers/partners

By enforcing a strict uni-directional linking of roles this can be very 
manageable, since each party will need to relate to 1-3 other role.
https://medium.com/@ensby/a-possible-couchdb-application-ecosystem-e39ac4397cea 


johs

PS

About the 10 roles
To create a market, we need to specialize and stop the practice that "everyone 
is doing everything".
When every site is built and modified from scratch and everyone is stitching 
together any selection of frameworks and solutions, we are like the carpenter 
that makes his own tools, but decide to become a blacksmith too, since he does 
not like the only blacksmith in the village. The problem is that the tradesman 
that provide steel will not sell to carpenters who does know so little about 
steel, especially since he is asking for free advice all the time, so the 
carpenter decides to go into the mountain and find some ore to make his own 
steel.
This problem would have been solved if the village had 2 blacksmiths.

We need at least 3 players in each role to create an ecosystem.
To start with we can hold several each.

About javascript framework I have a dilemma, go for ermouth's jQueryMy which is 
extremely efficient and has the beauty of easy integration for widgets into 
Inliner (actually you can have a dynamic view of widgets pop up in Inliner and 
as easy to include as adding and cropping an image. 
My other alternative is to use Vue.js as I have the feeling that it will suit 
the simplicity goal.
I would appreciate advice.

See this tweet for a comparison of frameworks.
https://twitter.com/search?q=Github-star-to-contributor%20ratio&src=typd 

The trade-off between few developers (clean code) and wide following is on this 
range:
Angular: 33 Github stars per contributor
React: 56
Ember: 28
Vue: 265 (has now 9 277 stars and is showing up on Google trends, rising 
together with React https://twitter.com/ensby/status/663666399911518208)
jQueryMy: 923

If you would like to share this with people that you might think would be 
interested you could use this tweet
https://twitter.com/ensby/status/663977466864758784

Re: CouchApp build tools

[Johs Ensby]

Absolutely agree,
the message to new developers being: You can postpone your efforts in learning 
to user Github, Grunt and all the other tools used the be the developer's 
"license to trade".

johs

> On 9. nov. 2015, at 13.03, Giovanni Lenzi  wrote:
> 
> P.S. I only forgot to mention that we have the luck that couchdb is one of
> the few db/app server with a native HTTP API . Doesn't an in-browser IDE
> feel like the natural choice for its couchapp development and deployment
> environment?

Ecosystem around CouchDB applications

[Johs Ensby]

Hi All,

I have written the followup Applications in CouchDB article
I am afraid this will be a 10+ minute read, I had to establish a vocabulary to 
get to what I propose
https://medium.com/@ensby/a-possible-couchdb-application-ecosystem-e39ac4397cea 



The first article is here
 to the https://medium.com/@ensby/applications-in-couchdb-946a9c19015 


Thanks for the comments on the first article.

Johs

Re: CouchApp build tools

[Johs Ensby]

Aurélien,

skipping Gitub and version tracking is in a context where you have junior 
developer doing small web sites as modifications of some template sites and 
another developer maintaining css on several similar small sites. If a third 
person is needed for content updates, complicated updates are easily thrown 
from the content manger (using Inliner, a Ddoc Lab companion application) to 
the developer and back easily. 

One use case is event sites with lots of content changes and paralell needs to 
reformat and tweek the presentations in terms of templates, css and some couch 
stuff.
To think of the site as a new version with staging sites worked out very well. 

Site versions "Live", "tomorrow" and "nextweek" then become the versions I want 
to control.
Instead of tracing the changes of single lines of code the version control is 
about entire sites that change from week to week and in the most hectic periods 
from day to day.

Far from all of the smart things you can do with Ddoc Lab has been documented 
yet, but I think it is very promising.

Your idea to use it to teach CouchDB is where we see the same, I think.  it's 
very illustrative, but the reason I am such a fan is that I see the possibility 
of turning a junior developer into a productive site manager much more quickly 
than on any other tool/platform. With a few tweeks to the application server 
functionality of CouchDB this will outperform LAMP and more modern equvalent 
stacks.

Johs


> On 5. nov. 2015, at 11.48, Aurélien Bénel  wrote:
> 
>> the advandage I see (…) is that we skipped Github fir ddocs because it 
>> actually works well in a team too.
> 
> Do you mean that you completely skipped version control? As for us, we 
> couldn’t do that.
> 
> Don’t take it personally, Ddoc.me is really interesting (and I think I will 
> use it to teach CouchDB). But there is still a need for a command line tool 
> for teams that require traceability, visibility or testability. 
> 
> 
> Regards,
> 
> Aurélien

Re: CouchApp build tools

[Johs Ensby]

ermouth,
your roadmap for Ddoc Lab is very ambitious.
Please advice on how we as a community can contribute to #1 on the list.

johs


> On 5. nov. 2015, at 17.38, ermouth  wrote:
> 
>> Do you mean that you completely skipped version control?
> 
> Since DdocLab source docs are PouchDB/CouchDB/Barrel docs, and have
> revisions, actually, there exist version control. UI of public version does
> not give you control over revisions, but it‘s a matter of time. I
> personally use aside mechanics for it, and this mechanics will be
> eventually merged inside Ddoc Lab. Task isn‘t so easy, cause we need to be
> protected from accidental DB compaction.
> 
> TWIMC, current roadmap for Ddoc Lab is:
> 
> 1. Create good manual – too many features are now hidden under small UI
> buttons/checkboxes.
> 2. Add TAR as a special attach type, able to combine several files into it
> – to allow `npm install
> http://localhost:5984/db/_design/ddoc/npmPackage.tar` scenario
> 3. Add jsondiff component to allow source revisions comparison
> 4. Add github support (first one way, then two way)
> 5. Add Erlang editor (to allow Erlang views etc)
> 
> ermouth
> 
> ermouth
> 
> 2015-11-05 13:48 GMT+03:00 Aurélien Bénel :
> 
>>> the advandage I see (…) is that we skipped Github fir ddocs because it
>> actually works well in a team too.
>> 
>> Do you mean that you completely skipped version control? As for us, we
>> couldn’t do that.
>> 
>> Don’t take it personally, Ddoc.me is really interesting (and I think I
>> will use it to teach CouchDB). But there is still a need for a command line
>> tool for teams that require traceability, visibility or testability.
>> 
>> 
>> Regards,
>> 
>> Aurélien

Re: CouchApp build tools

[Johs Ensby]

Aurélien,
I agree with you the python app is good and that is probably why I never got 
around to try Erica where I am sure Beniot did a good job with.
Compatibility with a file structure would not be complicated, I would think, 
but the advandage I see in Ddoc is that we skipped Github fir ddocs because it 
actually works well in a team too. Instead of folders in a file it holds a 
couch document as the source document and outputs projects as ddoc.

If someone you tried all three alternatives could make a comparison and feature 
matrix that would be great

johs
 

> On 5. nov. 2015, at 10.40, Aurélien Bénel  wrote:
> 
>>> Is there a plan to install one implementation automatically with CouchDB? 
>>> That would be great.
>>> However the chosen version should pass tests to be sure that it implements 
>>> all the features that are used by people on a daily basis. I had bad 
>>> experiences earlier when I tried to replace python couchapp tool with 
>>> alternatives.
>> ermouth has created this tool which I can recommend 
>> It is a IDE in the form of a single design document so it is convenient to 
>> have in any couch database where you need it. (…) The beauty of it is that 
>> it is offline based on PouchDB so you have a super UX
> 
> Thanks Johs. This is an interesting project. However a must-have for us is :
> - to keep our git-based folders (with the same structure if possible), 
> - to use our favorite editors (MacVim for me, other editors for 
> collaborators), 
> - to push the app with a command line (so that it can be launched by 
> Travis.ci for example).
> 
> As a matter of fact, we’re quite happy with python couchapp! 
> 
> The only problem with it is that its installation takes 16s on Travis.ci and 
> that it is regularly broken and hard to reinstall on MacOS X updates.
> 
> 
> Regards,
> 
> Aurélien

Re: CouchApp build tools

[Johs Ensby]

Hi Aurélien,
ermouth has created this tool which I can recommend
http://ddoc.me/ 

It is a IDE in the form of a single design document so it is convenient to have 
in any couch database where you need it.
I cut & paste the json document into Fauxton or install it with one curl 
command, I guess.
The beuty of it is that it is offline based on PouchDB so you have a super UX

Johs


> On 5. nov. 2015, at 09.26, Aurélien Bénel  wrote:
> 
> Good morning Couchappers,
> 
>> anyone who want to share experiences and preferences?
> 
> Is there a plan to install one implementation automatically with CouchDB? 
> That would be great.
> 
> However the chosen version should pass tests to be sure that it implements 
> all the features that are used by people on a daily basis. I had bad 
> experiences earlier when I tried to replace python couchapp tool with 
> alternatives.
> 
> 
> Regards,
> 
> Aurélien

CouchApp build tools

[Johs Ensby]

Hi,
I would take this message from Miroslav as an opportunity to start a new thread.
The confusion bewteen applications in CouchDB and the tool to build such 
(design docs) started, I guess when the first tool was called CouchApp.

So the ones I knwo are

Couchapp
Erica
Ddoc Lab

any more around?
anyone who want to share expereinces and preferences?

Johs

> On 5. nov. 2015, at 09.13, Miroslav Rodic  wrote:
> 
> There is a version written in pure Erlang:
> 
> https://github.com/benoitc/erica
> 
> 
> 
> 

A strategy for applications in CouchDB

[Johs Ensby]

Hi All,
I am working on a set of articles that I hope will help the discussion around 
CouchApps
Here's the first one
https://medium.com/@ensby/applications-in-couchdb-946a9c19015 


johs

Re: [ANNOUNCE] CouchApp ML

[Johs Ensby]

Thanks, Alexander
johs

> On 3. nov. 2015, at 19.35, Alexander Shorin  wrote:
> 
> Hi everyone!
> 
> I'm happy to announce our new ML: couchapp@couchdb.apache.org !
> 
> TL:DR mailto:couchapp-subscr...@couchdb.apache.org
> 
> Recently we had quite hot discussions around about CouchApps and their
> future. This is complex topic, that lies on the border line of user,
> dev and marketing ML, so it's good to have special place where we can
> continue our conversations for the great good.
> 
> Another part of the story is that we'll need to restore CouchApp as a
> brand, define it future (if any) and help each other with working on
> them. And couchapp ML is the best place where we can do all of that
> and even more.
> 
> So, everyone who loves this feature, would like to help us to make it
> better and wanted to participant in are welcome! (:
> 
> --
> ,,,^..^,,,