> 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. 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. > 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. 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/
