On Thu, May 7, 2015 at 1:14 PM, Jan Lehnardt <[email protected]> wrote:
I never said CouchApps should be removed. Can everybody please stop
refuting a point that I never made. And lay off the personal attacks while
you are at it.
Best
Jan
--
On 07.05.2015, at 11:16, Harald Kisch <[email protected]> wrote:
Sorry guys, my eyes dont believe what they see..
@Jan: How are you? long time not spoken to eachother. How is Lena? What
she
is thinking about couchapps?
Why not to make a list of pros and cons for couchapps?
Did you ask jchris about removing couchapps?
Or why you don't directly ask Damien aboout the cause he implements it?
What is your benefit removing it?
For my part I have been successfully using it since 2008 and this is my
favorite use case for building secure, anywhere applications for the
industry and I would apreciate improvements on couchapps regarding
Authentication, LDAP and Active Directory erlang modules like built in
2010
and never improved.
We should not forget what CouchDB is all about. And for me the guys who
claim out to remove couchapp simply forget the power Damien have built in
and the power who made CouchDB proud to kick-off the no-sql area.
Dont forget who Damien really is. He is one of the leading developers of
Domino Notes aka Lotus Notes aka IBM Notes, registering 3 patents in USA
for it. Because only older guys know it, Lotus Notes was the previously
business standard groupware software for large scale companies before SAP
was destroying it's reputations with the help of IBM (which wanted only
to
sell their DB2 Database). Everybody who was working with Lotus Notes
begun
to love it. Not so SAP-Users, they are hating their daily work with SAP
because it simply don't work (complexity).
Couchapp is not complex and still have the power lotus notes has.
Remember:
Damien has built CouchDB because "everybody was talking about it, and
nobody did it", until Damien got it done with CouchDB.
In my opinion, and there are much more people who think in this way,
Couchapp is the most important and game-changing feature in CouchDB. But
also most misunderstood and most criticised, partly because of the fear
it
creates amoung other database vendors who always want exactly this:
Application execution directly out of the database core. Yes, exactly
this
is Couchapp! And it does it without CLR (Microsoft SQLSERVER) or JAVA
(Oracle Forms) and its terribly complex architecture.
Please stop using CouchDB as stupid data container and think more about
it
as Web-Application-Engine!
Cheers
Harald Kisch
---
Given the importance of this topic: the future of couchapp... I'm moving
this to the user@ mailing list.
This should be definitely something @users should be involved in.. at
least
those interested in Couchapps.
To recap:
Jan: wants to remove Couchapp name and design doc functions because it
finds them to be source of confusion
ermouth: pointed out Couchapps are not silver bullet but they cover many
use cases and there are rooms for improvements
giovanni: pointed out many users and industries today are using couchapps
successfully, withouth such this confusion between what couchdb is and
what
couchapps are, and they won't simply understand couchapps removal,
leading
couchdb to a second-death. Moreover couchapps potential has increased a
lot
within the last months: now they are secure and has support for features
like e-mail, sms, paypal/stripe integration, events scheduling.
johs: pointed out couchapps are big recruiter for couchdb and they should
not be dropped: a fadeout of "couchapp" name withouth any removal should
be
sufficient
andy: was not aware of the name confusion, and wanted to keep the name
What you all think about it?
2015-05-05 22:35 GMT+02:00 Giovanni Lenzi <[email protected]>:
Agree with Andy.. why change a name of something that is born with
couchdb, lives in couchdb and runs only inside of it?
Dropping name or removing it won't simply be understood by users and
industries already relying on it. imho negative impact could be very
high..
and I'm afraid this could really lead to a new second death for the
project, after the first one with the damien katz retirement issue...
all of the above can't be justified with only some naming conflicts,
even
considered that couchapp tools and also couchappy project have changed
their name just to prevent it
More than a naming confusion, i'm aware of a lack of clarification about
what can and cannot be done, supported by facts, real examples and
eventually benchmarks
Furthermore, so far on social networks I have seen more focus on what
cannot be done, instead of the contrary.. and I can well understand
users
can be afraid and confused by this.
Il giorno 05/mag/2015 20:33, "Andy Wenk" <[email protected]> ha
scritto:
On 5 May 2015 at 18:44, Jan Lehnardt <[email protected]> wrote:
On 05 May 2015, at 18:37, Andy Wenk <[email protected]> wrote:
As often, here are many truths in all the replies. I see myself just
jumping in from the side because I don't actually use CouchApps. I
have
full respect for people like Giovanni who want to keep CouchApps
'alive'.
So I think the plan Jan wrote done can work quite good also for me.
Here
are my comments:
On 5 May 2015 at 17:39, Jan Lehnardt <[email protected]> wrote:
Thanks for bringing up naming and design docs!
There are a few angles here, that make it harder for me to think
about
this. I’ll try to spell it all out.
Design Docs: The learning curve of design docs is really, really
steep
and
the usability is so bad, that we need third-party tools to work
around
this.
When we met in Boston a couple of years ago, we agreed that we
should be
addressing this. Mango is the first concrete step into a future
where
CouchDB indexing is more of an API and less of a “compile JS into
JSON
into
a doc with a weird name”. I believe that this is the way forward.
I think everything that is in a ddoc could equally be hidden behind
an
API
like mango does. Under the hood, it’s still design docs, but the
interface
would be A LOT more friendly.
With 2.0 and Mango I’d hope that 90% of our users don’t have to
touch
ddocs anymore for basic CouchDB querying. I’d love to extend this
to
document update validations and filters as well.
(See, now this turns into a future-of-couchdb discussion, sorry
about
that).
With nice APIs for all core features, there’d be less need for a
tool
that
manages design docs.
What CouchApps can *do* today, would, however, still be possible.
Which brings me to naming.
CouchApp is:
- a python tool
- a nodejs tool
- is implemented in the erlang tool erica
- is a concept of how to put a *very specific type of app* into
CouchDB
- a domain couchapp.com/.org
- a way to manage design documents (which have their own problems,
see
above)
- the second thing people get to hear, when they ask about how do I
query
CouchDB?
- a lose collection of features inside CouchDB that all have
problems:
- rewrite: not flexible enough, web devs expect more options for
routing
- show/list/update/filter/validate: terrible performance
characteristics
- map/reduce views: complicated (yet powerful), mediocre performance
characteristics
- an url slug in our documentation:
http://docs.couchdb.org/en/1.6.1/couchapp/
- this creates an unfortunate hierarchy, yes, all the things in this
section are parts of the CouchApp idea, but e.g. doc update
validations
are
a valid concept even if you need nothing else from the CouchApp
idea.
This is very very very very confusing and we need to clean it up.
* * *
I very much sympathise with ermouth’s story-of-couchapp email. I’ve
been
through similar steps and everyone I know who has taken CouchApps to
an
extreme (Caolan McMahon of Kanso, Dale Harvey of PouchDB, Gregor
Martynus
of Hoodie, just to name a select few) all have similar stories.
CouchApps
appear genius at first, until you try to build a wide range of
things
with
them.
At this point, I’m no longer interested what neat things can be done
with
CouchDB, but I want to make sure we polish the core features as much
as
we
can so they are easy to understand and use and don’t bring surprises
operationally.
I don’t mean to kill the concept of CouchApps, but the situation
today
is
very damaging to our user-adoption rate. I’m more than happy to keep
the
functionality around, because I see there is merit in having it. But
*most*
CouchDB users I see, shouldn’t not be confused with whatever
“CouchApp”
means when they just want a database that replicates, when they want
to
put
their data where they need it.
So yeah, sorry, I don’t think this should be a recruiting vehicle
for
CouchDB.
Here is a scenario that I can see working:
1. establish the idea of applications-in-couchdb as a standalone
project
(can be part of ASF CouchDB) with a name that doesn’t have “couch”
in
it.
yes - but I don't understand why we can't keep the name CouchApp.
My main point here is that “couchapp” is too overloaded as a term and
really hard to change the meaning of, or reduce the meaning of to that
one specific thing that we want it to be.
And even *if* CouchApp could just mean “the concept of having apps in
your CouchDB”, it’d still confuse those users, that think that’s the
only way to use CouchDB and they walk away.
To be honest, I am not aware that it is such a big problem but as you
are
way more in contact with users, I take it for granted.
I don’t think CouchApps 2.0 is going to help. Especially with CouchDB
2.0 coming up, I see even more confusion and less clarity.
My thought was this: we celebrate both CouchDB 2.0 and CouchApp 2.0 and
hammer as long as needed on the point how we want CouchApps to be
seen. I
thought it's a great chance to clearly separate the two different
things
when CouchDB 2.0 is released. But I know it is tremendously difficult
to
achieve the wanted result communication wise. Maybe the task is too
heavy
but I can remember various projects that said "Since version x.y we
decided
to separate this and that from the main project". But I also admit
that I
also remember that it still was needed to clarify the situation
afterwards
for some folks ('Why is this not there anymore?' .... 'They dropped it
in
2.0' ... 'Ah ok - did not know').
We have that name and we have a domain for it.
I mentioned diminishing returns, just because we invested in something
that doesn’t mean it makes sense holding on to it for the future.
sure not ;-). My intention is to keep it so that's the reason why I
promote
my idea sustained. But that's the point of view I have at the moment
and
I
don't insist on it. If we find the common consensus that we should let
the
term CouchApp die, that's ok with me.
All the best
Andy
Thanks for your support on the other points.
Best
Jan
--
As I said before, we have to clarify
extremely well what the project folks think about CouchApps. I could
imagine to let Giovanni work on that page with our support.
2. provide APIs for all design-doc-features, so we don’t need extra
tooling with CouchDB (maybe a little bit like couchdb-cli that
rkowalski is
toying with, but we’d ship that with CouchDB)
yes
3. Turn all 1.x-level CouchApp features (shows, lists, updates,
vhosts,
rewrites) into a plugin (can be installed by default, and maybe
later
not).
The plugin then can evolve independently from CouchDB and implement
e.g.
more efficient list functions.
yes
4. publicly celebrate the retirement of all things “CouchApp” with
pointers on couchapp.org/.com to where the things “CouchApps” were
used
for are available now, without confusion.
The story then is:
- In 1.x some parts of the CouchDB API were too complicated, we had
to
have a tool for it.
- The tool also allowed to build standalone web applications that
solely
live in CouchDB.
- All this is now available elsewhere under these new names: X, Y,
Z.
- R.I.P. CouchApps.
I still don't understand why we have to bury CouchApp, but maybe I am
missing some key thoughts here. Imho we could also tell:
- In 1.x some parts of the CouchDB API were too complicated, we had
to
have
a tool for it.
- The tool also allowed to build standalone web applications that
solely
live in CouchDB called a CouchApp.
- We realised that this approach was resulting in some problems and
decided
to move them out of CouchDB.
- All this is now available as (e.g.) Plugins at couchapp.org and is
called
CouchApp 2.0
- We had a good idea, learned and decided that it is better to give
CouchApps it's own environment
TL;DR; we learned form the first attempt and the result is a own
place
for
CouchApps. We have the name, we have the domain and what we need is
clarification (sorry for repeating myself).
Thoughts?
Cheers
Andy
* * *
We have talked about focussing the CouchDB message and we agreed
that
replication and its ecosystem are the prime story to tell. I believe
CouchApps are a huge distraction from that story and we should own
to
retire it.
* * *
So far my thoughts. I realise people have invested a lot in
CouchApps (I
know I have for 5+ years), but we have to be looking out for CouchDB
and
see where we run into diminishing returns. It took me more than half
a
decade to learn that CouchApps harm CouchDB more than they help. We
as
the
project shouldn’t focus on what is technically neat/cool, but how
we
can
get more people to use our project because it fits their needs and
is
easily accessible. We have many other fronts to fight to get this
right,
but with CouchApps, we have a foot firmly on a break when it comes
to
making CouchDB more accessible.
* * *
I know this is a lot to take in. Take your time. You might want to
refrain
from knee-jerk-replies of the “but but but CouchApps are cool…”
type. I
understand. I think they are cool too.
Best
Jan
--
On 05 May 2015, at 16:52, Johs Ensby <[email protected]> wrote:
Cudos to Giovanni for CouchApp enthusiasm
and to Ermouth for harsh critisim
to Jan and Andy for addressing the “story” level
In spite of its many shortcomings, I still believe couchApps could
be
the big recruiter for CouchDB.
The fact that you can make a design document, direct a vhost to
its
_rewrite and there create your api for accessing multiple databases
with
various access levels and multiple design documents is awesome.
The main storytelling problem is the overselling as Ermouth points
out.
The overselling starts with the name itself, it should not have
“app”
in
it.
The concept of a CouchDB app is wrong.
The “app” that a million young developers are waiting to create
lives
in
the client.
They need to learn some CSS and a Javascript framework, and CouchDB
is
the only backend they will need until they find out that they need
more
in
addition to CouchDB.
We should quit telling the story about CouchApps and start telling
the
story of design docs.
CouchDB design documents are great.
At least as long as we keep it simple.
Our quest should be for powerful simplicity.
Simplicity always win.
Johs
On 05 May 2015, at 11:49, Jan Lehnardt <[email protected]>
wrote:
On 05 May 2015, at 11:08, Andy Wenk <[email protected]>
wrote:
Hi,
Jan thanks for raising this important topic!
As I had been around and participated when JChris, Jan
and others
started
CouchApps and Benoit took over the work, I am a bit sad,
that
CouchApps
started to confuse people. And yes it is true, they are
limited
but
have
their place in the history of CouchDB. Far more, it can
easily be
seen
as
the evolutionary basis for Hoodie and that is a good thing
imho.
We should give CouchApps a place to live in the CouchDB
ecosystem
(not
meant technically). So my proposal is to reactivate couchapp.org
and
write
one page with info about
* what CouchApps are
* how one can create one (links to doku)
* what alternatives there are (kanso, hoodie ...)
Furthermore we should include a link on couchdb.org to
couchapp.org.
I think it would be wrong to leave people still in the
dark even
though
nowadays we think, CouchApps is not the way one should
create a
WebApp
based on CouchDB (and I don't think the approaches to create
CouchApps
was
foolish Jan ;-)). It is our responsibility to clarify what
CouchApps
are
and why one should move forward to sth. better. With
clarification
comes
clarity
Thanks Andy! — I’m all for the things you mention, once
we figure
out
how
the CouchApps story fits into the larger CouchDB story without
confusing
anyone.
What’s your take on that? :)
* * *
Also, I think we shouldn’t be afraid to make CouchApp’s
place in
CouchDB’s
history clear in terms of “This was an idea of its time.
Today, we
think
differently. RIP CouchApps”.
Best
Jan
--
All the best
Andy
On 5 May 2015 at 10:54, Jan Lehnardt <[email protected]>
wrote:
It seems we have a separate discussion going on here,
so I forked
the
thread.
I’ve seen these two sides ever since we invented
CouchApps:
Pro:
- CouchApps are amazingly simple
- CouchDB as an app server is a great idea, I don’t
need to run
any
other
infrastructure
- this is the future of web development
- couchapp* is a great tool to manage design docs
(*or erica… etc.)
Con:
- the concept of compiling design docs is confusing
- even when they get it, they are confused that they
need a third
party
tool called `couchapp` to do so, because the documentation
talks
about
building full apps in CouchDB, they have an external
app and just
want to
use CouchDB as a database, but couchapp is still the
tool they
need.
- the tooling is poor
- the tooling is all third-party
- they can only cover a very limited use-case
- CouchApps are the only way to use CouchDB
I see a number of people being passionate about CouchApps
and I
believe
their enthusiasm is warranted, CouchApps are a neat
idea.
But I also see a greater number of people being confused
by
CouchApps
and
in turn by CouchDB.
That is not a good situation.
Let’s think about how (and if) we can fit the CouchApp
story
into a
coherent CouchDB story.
A prerequisite for that is having a coherent CouchDB
story,
which we
don’t
have fully finalised yet, but we have talked about
extensively,
and
the
consensus is around the “Data where you need it”
narrative that
emphasises
replication between CouchDB instances and other projects
that
speak
the
replication protocol (especially PouchDB and TouchDB).
How do CouchApps fit into that narrative?
* * *
(Personal view alert: this is just to give some more
background
on
my
own
position, this isn’t meant as a basis for discussion)
I’m personally conflicted. When we set out to develop
CouchApps,
we
thought we are inventing a new paradigm for how to
build the web,
and
everybody would follow us, because that would enable
a true p2p
web.
That
didn’t happen and probably was a little foolish of
us :D
Technically, that would have meant CouchApps had to
grow a lot
more
and I
realised quickly that CouchDB is not the right place
to grow
such a
thing.
In addition, there are various fully fledged web frameworks
already
and
CouchApps could never really compete in terms of person-power
and
attention.
That all led me to re-evaluate the whole value proposition,
when
things
like PouchDB came up and the browser became a decent
application
development platform. That whole thinking led to the
creation of
Hoodie (
http://hood.ie), which started out with the code name
CANG
(Couch
Apps
Next Generation), where we liked some of the core ideas
of
CouchApps,
but
wanted to address the limitations that would stifle
their
adoption.
Hoodie
embraces browser-to-server sync to allow fully offline
apps, it
allows
all-javascript-all-json development on the front- and
back-end.
It
uses the
database-per-user and the _changes-feed-as-async-worker
paradigms
and
it is
all wrapped into a package that is *really* easy to
understand
and
get
started with. Hoodie, unlike CouchApps, does have a
fighting
chance
of
making CouchDB’s unique features (replication, _changes)
available
for a
larger population and I’m infinitely excited about
that.
* * *
All that doesn’t mean, however, that CouchApps don’t
have their
place, but
again, I’m not sure where that place is and the place
it
currently
has
seems to negatively affect CouchDB, so I’d like for
this list to
think and
talk about all that for a bit.
How can we make it that CouchApps strengthen CouchDB
and not
weaken
it by
adding confusion?
How do CouchApps fit into the CouchDB story?
Best
Jan
--
On 05 May 2015, at 08:45, ermouth <[email protected]>
wrote:
CouchDB-killing answers
Well... When someone says couchapps is silver bullet
– I say
‘No’
and I
can
prove it. Couchapps have a lot, A LOT of problems,
and some of
them
can
not
be solved inside CouchDB. For example, try to implement
ACL for
attachments
or try to scale couchapp. You just can‘t do it
in reasonable
way.
I know several engineers who tried out couchapps
– and left
CouchDB
forever. Not because CouchDB itself, but because
couchapps.
O‘Reilly
said
it‘s a silver bullet, others said – and what
we have? Sloppy and
hard-to-debug architecture, that does not scale,
has no tooling
and
a lot
of security issues.
You gonna solve architecture problems with positive
posts?
What I want to say – there is no need to lie
and say couchapps
are
great.
Because they are not.
would you like to write down some of your positive:-))
experiences?
http://ermouth.livejournal.com/tag/couchdb –
sorry, Russian
language.
ermouth
--
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/
--
Andy Wenk
Hamburg - Germany
RockIt!
GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3
9ED3 9588
https://people.apache.org/keys/committer/andywenk.asc
--
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/<
http://www.neighbourhood.ie/couchdb-support/>
--
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/
--
Andy Wenk
Hamburg - Germany
RockIt!
GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588
https://people.apache.org/keys/committer/andywenk.asc
--
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/
--
Andy Wenk
Hamburg - Germany
RockIt!
GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588
https://people.apache.org/keys/committer/andywenk.asc
