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