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/content/dyn/closer.

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 to maintain it for security pa

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 

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: 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 <ermo...@gmail.com> 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 <j...@b2w.com>:
> 
>> 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: 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 <ermo...@gmail.com> 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 <ermo...@gmail.com>:
> 
>>> - 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 <j...@b2w.com>:
>> 
>>> 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 <ermo...@gmail.com> 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.

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: 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 <kxe...@gmail.com> wrote:
> 
> On Thu, Nov 19, 2015 at 1:05 AM, Johs Ensby <j...@b2w.com> wrote:
>> Couch-on-port-443-for-ubuntu recipe for dummies?
> 
> Sounds good. However, cannot help here since I'm on Gentoo P:
> 
> --
> ,,,^..^,,,

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 <i...@martinbroerse.com> 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 <i...@martinbroerse.com>
> Date: Sun, Nov 15, 2015 at 8:28 AM
> Subject: Re: Meet copy-couch!
> To: Johs Ensby <j...@b2w.com>
> 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 <j...@b2w.com> 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 <i...@martinbroerse.com>
>> 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 <byo...@bigbluehat.com>
>>> 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: 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 <j...@b2w.com> 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

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