Have not really been doing anything with Couchdb in the last couple years, as work keeps me on other things so my 2 cents might not be worth that much but :
1 I have a personal project that I want to get back into and it can benefit from couchapps. 2. I would like to see hard data before believing there was any name confusion. >>Please stop using CouchDB as stupid data container and think more about it >>as Web-Application-Engine! there might be a source of name confusion there, because having db in name implies data container. It is the apps in name that tells you Web-Application-Engine is part of it. Thanks, Bryan Rasmussen On Thu, May 7, 2015 at 11:16 AM, 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 >>> >>
