On 5 May 2015 at 18:44, Jan Lehnardt <j...@apache.org> wrote:
>
> > On 05 May 2015, at 18:37, Andy Wenk <andyw...@apache.org> 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 <j...@apache.org> 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 <j...@b2w.com> 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 <j...@apache.org> wrote:
> >>>>
> >>>>>
> >>>>> On 05 May 2015, at 11:08, Andy Wenk <andyw...@apache.org> 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 <j...@apache.org> 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 <ermo...@gmail.com> 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
