Funny how this proves my point about CouchApps being confusing. We can't even talk about their future without talking past each other.
In addition, cherry-picking quotes from my emails won't help to clarify things. I understand you *can* read a position of "let's remove CouchApps" into what I wrote, by only if you selectively ignore some of the things I also said. I don't think that is useful. Please join marketing@ to join the uncut discussion there. Best Jan -- Best Jan -- > On 07.05.2015, at 15:10, Harald Kisch <[email protected]> wrote: > > Sorry Jan, please don't take it personally but in your both emails you > definitely claimed out, that couchapps does'nt fit in YOUR CouchDB-Story. > > In > > http://markmail.org/message/no3jfksdxjcgxz4d > > you personally said: > "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." > > Sorry but for me it means you don't want CouchDB to have an App-Engine > inside. The only confusion is: What could be the issue for that? Every > database vendor works for decades on it? And why peer-to-peer should be > bad? Think on Git, torrent network, etc. pp. are these projects not the > leading inventions of the last decades based on peer-to-peer? And yes, > CouchDB is NOW extremely powerful with Apps executed out of its database > core and replicated anywhere without the need of permanent internet > connection! > > Also in > > http://markmail.org/message/xla3hulea4lo5duw > > you personally said: > "figure out a plan to retire “CouchApp”" > > Sorry this words are not misunderstandable for me. And I am wondering why > and how you can say that. And if you really want to "retire CouchApp" > because of confusions (for me it is the other way around - the storage is > part of the App-Engine because stupid containers you can find everywhere > based on node.js etc. to support the same as CouchDB's native App > Core-Feature called Couchapp) > > CouchApps for me "are" the CouchDB Story. There is no confusion about that. > Please do not claim that somone has something against you and please take > it objective not emotional. But if you take such desruptive things into the > community, you should also stand for it to explain them accordingly and not > start to change the basics to loose all the current users of that > game-changing core-feature. > > Best > Harald > >> 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 >>
