Return-Path: X-Original-To: apmail-couchdb-marketing-archive@minotaur.apache.org Delivered-To: apmail-couchdb-marketing-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id EBF74182D3 for ; Wed, 6 May 2015 07:05:40 +0000 (UTC) Received: (qmail 43549 invoked by uid 500); 6 May 2015 07:05:40 -0000 Delivered-To: apmail-couchdb-marketing-archive@couchdb.apache.org Received: (qmail 43515 invoked by uid 500); 6 May 2015 07:05:40 -0000 Mailing-List: contact marketing-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: marketing@couchdb.apache.org Delivered-To: mailing list marketing@couchdb.apache.org Received: (qmail 43503 invoked by uid 99); 6 May 2015 07:05:40 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 May 2015 07:05:40 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: message received from 54.164.171.186 which is an MX secondary for marketing@couchdb.apache.org) Received: from [54.164.171.186] (HELO mx1-us-east.apache.org) (54.164.171.186) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 May 2015 07:05:35 +0000 Received: from smtpcmd02111.aruba.it (smtpcmd02111.aruba.it [62.149.158.111]) by mx1-us-east.apache.org (ASF Mail Server at mx1-us-east.apache.org) with ESMTP id A8AA042AA7 for ; Wed, 6 May 2015 07:05:13 +0000 (UTC) Received: from mail-ie0-f175.google.com ([209.85.223.175]) by smtpcmd02.ad.aruba.it with bizsmtp id QX541q01P3ngQoH01X5502; Wed, 06 May 2015 09:05:06 +0200 Received: by ieczm2 with SMTP id zm2so7126933iec.2 for ; Wed, 06 May 2015 00:05:04 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.138.130 with SMTP id c2mr37940811ioj.74.1430895904974; Wed, 06 May 2015 00:05:04 -0700 (PDT) Received: by 10.107.57.193 with HTTP; Wed, 6 May 2015 00:05:04 -0700 (PDT) In-Reply-To: References: <33BD4D82-787C-48D5-B963-FEEA4C0913CB@apache.org> <4209351E-F51E-4DB5-8A5F-8AB53DA21877@apache.org> <0B891CED-B735-4D86-86D2-1C4CDF6BDE21@apache.org> Date: Wed, 6 May 2015 09:05:04 +0200 Message-ID: Subject: Re: How do CouchApps fit into the CouchDB story? (Was: CouchDB Articles, Pills and Tutorials Ideas) From: Giovanni Lenzi To: marketing@couchdb.apache.org Content-Type: multipart/alternative; boundary=001a113f284e206d3d0515646a32 X-Virus-Checked: Checked by ClamAV on apache.org --001a113f284e206d3d0515646a32 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree John, with all you said. - ddocs term is probably less confusing - fadeout of the word "couchapp" withouth killing - a separate project if it can effectively add more value to web-app development 2015-05-06 7:10 GMT+02:00 Johs Ensby : > Giovanni, > on the issue of the death of CouchApps, I think one opportunity is this: > CouchApp is (among all the other things that Jan listed) one or a set of > design documents > We have 2 names for the same thing, approximately > My suggestion is to start using ddocs, design docs or design documents an= d > let CouchApp fade out by itself, no killing needed > Jan, > I like the suggestion to separate CouchApps into a separate project. That > should start with > A defined target group > Clear design goals > A rigid plugin architecture > > The idea that I find very powerful is > Let the functionality follow the data > Databases have had stored procedures for ages, but what database provided > a methodology for letting functionality piggyback the data as easily as i= n > CouchDB? > Could there be a sweet spot between =E2=80=9Cconvenience functionality=E2= =80=9D for > advanced developers and what would be attractive to novice developers and > developers looking for a minimalistic tech stack? > > Thanks for listing the pioneers, Jan. Would anyone care to complete the > list of people that took CouchApps to the extreme and would be good > candidates for a roundtable on design goals for its future? > Caolan McMahon of Kanso @caolan > Dale Harvey of PouchDB @daleharvey > Gregor Martynus of Hoodie @einfachsmart > Ermouth of Cloudwall @ermouth > Giovanni of Smileupps @smileupps > > Johs > > > On 05 May 2015, at 22:35, Giovanni Lenzi wrote: > > > > 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, ev= en > > 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 abou= t > > 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 use= rs > > can be afraid and confused by this. > > Il giorno 05/mag/2015 20:33, "Andy Wenk" ha > scritto: > > > >> On 5 May 2015 at 18:44, Jan Lehnardt wrote: > >> > >>> > >>>> On 05 May 2015, at 18:37, Andy Wenk 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 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=E2=80=99ll 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 shou= ld > >> be > >>>>> addressing this. Mango is the first concrete step into a future whe= re > >>>>> CouchDB indexing is more of an API and less of a =E2=80=9Ccompile J= S into > JSON > >>> into > >>>>> a doc with a weird name=E2=80=9D. I believe that this is the way fo= rward. > >>>>> > >>>>> I think everything that is in a ddoc could equally be hidden behind > an > >>> API > >>>>> like mango does. Under the hood, it=E2=80=99s still design docs, bu= t the > >>> interface > >>>>> would be A LOT more friendly. > >>>>> > >>>>> With 2.0 and Mango I=E2=80=99d hope that 90% of our users don=E2=80= =99t have to touch > >>>>> ddocs anymore for basic CouchDB querying. I=E2=80=99d love to exten= d this to > >>>>> document update validations and filters as well. > >>>>> > >>>>> (See, now this turns into a future-of-couchdb discussion, sorry abo= ut > >>>>> that). > >>>>> > >>>>> With nice APIs for all core features, there=E2=80=99d 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 performanc= e > >>>>> 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 thi= s > >>>>> 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 ide= a. > >>>>> > >>>>> This is very very very very confusing and we need to clean it up. > >>>>> > >>>>> * * * > >>>>> > >>>>> I very much sympathise with ermouth=E2=80=99s story-of-couchapp ema= il. I=E2=80=99ve > >> been > >>>>> through similar steps and everyone I know who has taken CouchApps t= o > >> 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 thin= gs > >>> with > >>>>> them. > >>>>> > >>>>> At this point, I=E2=80=99m no longer interested what neat things ca= n be done > >>> with > >>>>> CouchDB, but I want to make sure we polish the core features as muc= h > >> as > >>> we > >>>>> can so they are easy to understand and use and don=E2=80=99t bring = surprises > >>>>> operationally. > >>>>> > >>>>> I don=E2=80=99t mean to kill the concept of CouchApps, but the situ= ation > today > >>> is > >>>>> very damaging to our user-adoption rate. I=E2=80=99m more than happ= y to keep > >> the > >>>>> functionality around, because I see there is merit in having it. Bu= t > >>> *most* > >>>>> CouchDB users I see, shouldn=E2=80=99t not be confused with whateve= r > >> =E2=80=9CCouchApp=E2=80=9D > >>>>> means when they just want a database that replicates, when they wan= t > >> to > >>> put > >>>>> their data where they need it. > >>>>> > >>>>> So yeah, sorry, I don=E2=80=99t think this should be a recruiting v= ehicle 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=E2=80=99t have = =E2=80=9Ccouch=E2=80=9D in > >>> it. > >>>>> > >>>> > >>>> yes - but I don't understand why we can't keep the name CouchApp. > >>> > >>> My main point here is that =E2=80=9Ccouchapp=E2=80=9D is too overload= ed as a term and > >>> really hard to change the meaning of, or reduce the meaning of to tha= t > >>> one specific thing that we want it to be. > >>> > >>> And even *if* CouchApp could just mean =E2=80=9Cthe concept of having= apps in > >>> your CouchDB=E2=80=9D, it=E2=80=99d still confuse those users, that t= hink that=E2=80=99s 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=E2=80=99t 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 an= d > >> 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 thin= gs > >> 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 tha= t > 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 somethin= g > >>> that doesn=E2=80=99t mean it makes sense holding on to it for the fut= ure. > >>> > >> > >> 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=E2=80=99t ne= ed extra > >>>>> tooling with CouchDB (maybe a little bit like couchdb-cli that > >>> rkowalski is > >>>>> toying with, but we=E2=80=99d 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 lat= er > >>> 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 =E2=80=9CCouchAp= p=E2=80=9D with > >>>>> pointers on couchapp.org/.com to where the things =E2=80=9CCouchApp= s=E2=80=9D 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 a= m > >>>> 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 pla= ce > >>> 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 th= at > >>>>> replication and its ecosystem are the prime story to tell. I believ= e > >>>>> 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 CouchAp= ps > >> (I > >>>>> know I have for 5+ years), but we have to be looking out for CouchD= B > >> and > >>>>> see where we run into diminishing returns. It took me more than hal= f > a > >>>>> decade to learn that CouchApps harm CouchDB more than they help. We > as > >>> the > >>>>> project shouldn=E2=80=99t focus on what is technically neat/cool, b= ut 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 =E2=80=9Cbut but but CouchApps are co= ol=E2=80=A6=E2=80=9D type. > >> I > >>>>> understand. I think they are cool too. > >>>>> > >>>>> Best > >>>>> Jan > >>>>> -- > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> On 05 May 2015, at 16:52, Johs Ensby wrote: > >>>>>> > >>>>>> Cudos to Giovanni for CouchApp enthusiasm > >>>>>> and to Ermouth for harsh critisim > >>>>>> to Jan and Andy for addressing the =E2=80=9Cstory=E2=80=9D 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 it= s > >>>>> _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 > =E2=80=9Capp=E2=80=9D > >>> in > >>>>> it. > >>>>>> > >>>>>> The concept of a CouchDB app is wrong. > >>>>>> The =E2=80=9Capp=E2=80=9D that a million young developers are wait= ing to create > lives > >>> in > >>>>> the client. > >>>>>> They need to learn some CSS and a Javascript framework, and CouchD= B > >> 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 wrote: > >>>>>>> > >>>>>>>> > >>>>>>>> On 05 May 2015, at 11:08, Andy Wenk wrote: > >>>>>>>> > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> Jan thanks for raising this important topic! > >>>>>>>> > >>>>>>>> As I had been around and participated when JChris, Jan and other= s > >>>>> 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 b= e > >>> 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 ecosyste= m > >>> (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 clarificati= on > >>>>> comes > >>>>>>>> clarity > >>>>>>> > >>>>>>> Thanks Andy! =E2=80=94 I=E2=80=99m all for the things you mention= , once we figure > >> out > >>>>> how > >>>>>>> the CouchApps story fits into the larger CouchDB story without > >>> confusing > >>>>>>> anyone. > >>>>>>> > >>>>>>> What=E2=80=99s your take on that? :) > >>>>>>> > >>>>>>> * * * > >>>>>>> > >>>>>>> Also, I think we shouldn=E2=80=99t be afraid to make CouchApp=E2= =80=99s place in > >>>>> CouchDB=E2=80=99s > >>>>>>> history clear in terms of =E2=80=9CThis was an idea of its time. = Today, we > >>> think > >>>>>>> differently. RIP CouchApps=E2=80=9D. > >>>>>>> > >>>>>>> > >>>>>>> Best > >>>>>>> Jan > >>>>>>> -- > >>>>>>> > >>>>>>>> > >>>>>>>> All the best > >>>>>>>> > >>>>>>>> Andy > >>>>>>>> > >>>>>>>> > >>>>>>>> On 5 May 2015 at 10:54, Jan Lehnardt wrote: > >>>>>>>> > >>>>>>>>> It seems we have a separate discussion going on here, so I fork= ed > >>> the > >>>>>>>>> thread. > >>>>>>>>> > >>>>>>>>> I=E2=80=99ve seen these two sides ever since we invented CouchA= pps: > >>>>>>>>> > >>>>>>>>> Pro: > >>>>>>>>> - CouchApps are amazingly simple > >>>>>>>>> - CouchDB as an app server is a great idea, I don=E2=80=99t nee= d to run > >> any > >>>>> other > >>>>>>>>> infrastructure > >>>>>>>>> - this is the future of web development > >>>>>>>>> - couchapp* is a great tool to manage design docs > >>>>>>>>> > >>>>>>>>> (*or erica=E2=80=A6 etc.) > >>>>>>>>> > >>>>>>>>> Con: > >>>>>>>>> - the concept of compiling design docs is confusing > >>>>>>>>> - even when they get it, they are confused that they need a thi= rd > >>>>> party > >>>>>>>>> tool called `couchapp` to do so, because the documentation talk= s > >>> about > >>>>>>>>> building full apps in CouchDB, they have an external app and ju= st > >>>>> 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=E2=80=99s 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, whi= ch > >> we > >>>>> don=E2=80=99t > >>>>>>>>> have fully finalised yet, but we have talked about extensively, > >> and > >>>>> the > >>>>>>>>> consensus is around the =E2=80=9CData where you need it=E2=80= =9D 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=E2=80=99t meant as a basis for discussion) > >>>>>>>>> > >>>>>>>>> I=E2=80=99m personally conflicted. When we set out to develop C= ouchApps, > >> we > >>>>>>>>> thought we are inventing a new paradigm for how to build the we= b, > >>> and > >>>>>>>>> everybody would follow us, because that would enable a true p2p > >> web. > >>>>> That > >>>>>>>>> didn=E2=80=99t 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 su= ch > >> a > >>>>> thing. > >>>>>>>>> In addition, there are various fully fledged web frameworks > >> already > >>>>> and > >>>>>>>>> CouchApps could never really compete in terms of person-power a= nd > >>>>> attention. > >>>>>>>>> > >>>>>>>>> That all led me to re-evaluate the whole value proposition, whe= n > >>>>> things > >>>>>>>>> like PouchDB came up and the browser became a decent applicatio= n > >>>>>>>>> development platform. That whole thinking led to the creation o= f > >>>>> 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 paradig= ms > >>> 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=E2=80=99s unique features (replication, _changes= ) > available > >>>>> for a > >>>>>>>>> larger population and I=E2=80=99m infinitely excited about that= . > >>>>>>>>> > >>>>>>>>> * * * > >>>>>>>>> > >>>>>>>>> All that doesn=E2=80=99t mean, however, that CouchApps don=E2= =80=99t have their > >>>>> place, but > >>>>>>>>> again, I=E2=80=99m not sure where that place is and the place i= t > currently > >>> has > >>>>>>>>> seems to negatively affect CouchDB, so I=E2=80=99d like for thi= s 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 wrote: > >>>>>>>>>> > >>>>>>>>>>> CouchDB-killing answers > >>>>>>>>>> > >>>>>>>>>> Well... When someone says couchapps is silver bullet =E2=80=93= I say > =E2=80=98No=E2=80=99 > >>>>> 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 fo= r > >>>>>>>>> attachments > >>>>>>>>>> or try to scale couchapp. You just can=E2=80=98t do it in reas= onable > way. > >>>>>>>>>> > >>>>>>>>>> I know several engineers who tried out couchapps =E2=80=93 and= left > >> CouchDB > >>>>>>>>>> forever. Not because CouchDB itself, but because couchapps. > >>> O=E2=80=98Reilly > >>>>> said > >>>>>>>>>> it=E2=80=98s a silver bullet, others said =E2=80=93 and what w= e have? Sloppy and > >>>>>>>>>> hard-to-debug architecture, that does not scale, has no toolin= g > >> and > >>>>> a lot > >>>>>>>>>> of security issues. > >>>>>>>>>> > >>>>>>>>>> You gonna solve architecture problems with positive posts? > >>>>>>>>>> > >>>>>>>>>> What I want to say =E2=80=93 there is no need to lie and say c= ouchapps > >> are > >>>>> great. > >>>>>>>>>> Because they are not. > >>>>>>>>>> > >>>>>>>>>>> would you like to write down some of your positive:-)) > >>> experiences? > >>>>>>>>>> > >>>>>>>>>> http://ermouth.livejournal.com/tag/couchdb =E2=80=93 sorry, Ru= ssian > >>>>> 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 95= 88 > >>>>>>>> > >>>>>>>> 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 > >> > > --001a113f284e206d3d0515646a32--