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
