> On 06 May 2015, at 18:14, Jan Lehnardt <j...@apache.org> wrote: > >> >> On 06 May 2015, at 17:57, Giovanni Lenzi <g.le...@smileupps.com> wrote: >> >> Given the importance of the topic: the future of couchapp... I'm moving >> this from the @marketing to the user@ mailing list. > > I’d say this is too early, would prefer we keep this on marketing@ until > we have the messaging right. Everything else follows from them.
…from that. > Given that > user@ is missing the entire “the why of CouchDB” context that marketing@ > has, I’d say moving this is premature. > > I also *could* see this as a cheap ploy to quickly garner public pressure > against my position, but in good faith, I won’t assume this is your motive. > > >> 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 > > This does not adequately reflects my position. I don’t suggest to remove > any of the things that make CouchApps possible. > > My larger argument can be found http://markmail.org/message/no3jfksdxjcgxz4d > and http://markmail.org/message/xla3hulea4lo5duw > > tl;dr: I’d like us to think about how the CouchApp (or whatever the > final name might be) story fits into the larger CouchDB story of “Data where > you need it.” — Not necessarily how the slogan made be “true” in the context > of CouchApps (e.g. “Data (and logic) where you need it.”, but more: > > - CouchDB’s core feature is geographically distributed replication. > > - Replication becomes really powerful with projects like PouchDB and TouchDB > that take individual user data offline on their browsers and phones. > > - The industry’s current battle is vendor-lock-in with proprietary backend as > a > service solutions that may or may not have offline capabilities. > > - CouchDB is the only serious Open Source contender in this. > > - We also have somewhat quirky, while technically neat, applications that can > live inside CouchDB. > > I don’t think that last bit helps paint the big picture CouchDB story at all. > Granted, I’m making a deliberately weak attempt of tying things together > (because I don’t know any better), but this is to get you thinking about how > this could fit in our larger narrative, if at all. > > My current thinking is that we can’t make it clear and thus should figure out > a > plan to retire “CouchApp”, while still allowing all the cool tech, and find a > new name for the concept that can live on without making CouchDB’s core > message > unclear. > > * * * > > Please join us on the marketing@couchdb.apache.org list for this discussion. > > Best > Jan > -- > > > >> >> 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 <g.le...@smileupps.com>: >> >>> 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" <andyw...@apache.org> ha scritto: >>> >>>> On 5 May 2015 at 18:44, Jan Lehnardt <j...@apache.org> wrote: >>>> >>>>> >>>>>> On 05 May 2015, at 18:37, Andy Wenk <andyw...@apache.org> wrote: >>>>>> >>>>>> As often, here are many truths in all the replies. I see myself just >>>>>> jumping in from the side because I don't actually use CouchApps. I >>>> have >>>>>> full respect for people like Giovanni who want to keep CouchApps >>>>> 'alive'. >>>>>> So I think the plan Jan wrote done can work quite good also for me. >>>> Here >>>>>> are my comments: >>>>>> >>>>>> On 5 May 2015 at 17:39, Jan Lehnardt <j...@apache.org> wrote: >>>>>> >>>>>>> Thanks for bringing up naming and design docs! >>>>>>> >>>>>>> There are a few angles here, that make it harder for me to think >>>> about >>>>>>> this. I’ll try to spell it all out. >>>>>>> >>>>>>> Design Docs: The learning curve of design docs is really, really >>>> steep >>>>> and >>>>>>> the usability is so bad, that we need third-party tools to work >>>> around >>>>> this. >>>>>>> >>>>>>> When we met in Boston a couple of years ago, we agreed that we >>>> should be >>>>>>> addressing this. Mango is the first concrete step into a future where >>>>>>> CouchDB indexing is more of an API and less of a “compile JS into >>>> JSON >>>>> into >>>>>>> a doc with a weird name”. I believe that this is the way forward. >>>>>>> >>>>>>> I think everything that is in a ddoc could equally be hidden behind >>>> an >>>>> API >>>>>>> like mango does. Under the hood, it’s still design docs, but the >>>>> interface >>>>>>> would be A LOT more friendly. >>>>>>> >>>>>>> With 2.0 and Mango I’d hope that 90% of our users don’t have to touch >>>>>>> ddocs anymore for basic CouchDB querying. I’d love to extend this to >>>>>>> document update validations and filters as well. >>>>>>> >>>>>>> (See, now this turns into a future-of-couchdb discussion, sorry about >>>>>>> that). >>>>>>> >>>>>>> With nice APIs for all core features, there’d be less need for a tool >>>>> that >>>>>>> manages design docs. >>>>>>> >>>>>>> What CouchApps can *do* today, would, however, still be possible. >>>>>>> >>>>>>> Which brings me to naming. >>>>>>> >>>>>>> CouchApp is: >>>>>>> - a python tool >>>>>>> - a nodejs tool >>>>>>> - is implemented in the erlang tool erica >>>>>>> - is a concept of how to put a *very specific type of app* into >>>> CouchDB >>>>>>> - a domain couchapp.com/.org >>>>>>> - a way to manage design documents (which have their own problems, >>>> see >>>>>>> above) >>>>>>> - the second thing people get to hear, when they ask about how do I >>>>> query >>>>>>> CouchDB? >>>>>>> - a lose collection of features inside CouchDB that all have >>>> problems: >>>>>>> - rewrite: not flexible enough, web devs expect more options for >>>> routing >>>>>>> - show/list/update/filter/validate: terrible performance >>>> characteristics >>>>>>> - map/reduce views: complicated (yet powerful), mediocre performance >>>>>>> characteristics >>>>>>> - an url slug in our documentation: >>>>>>> http://docs.couchdb.org/en/1.6.1/couchapp/ >>>>>>> - this creates an unfortunate hierarchy, yes, all the things in this >>>>>>> section are parts of the CouchApp idea, but e.g. doc update >>>> validations >>>>> are >>>>>>> a valid concept even if you need nothing else from the CouchApp idea. >>>>>>> >>>>>>> This is very very very very confusing and we need to clean it up. >>>>>>> >>>>>>> * * * >>>>>>> >>>>>>> I very much sympathise with ermouth’s story-of-couchapp email. I’ve >>>> been >>>>>>> through similar steps and everyone I know who has taken CouchApps to >>>> an >>>>>>> extreme (Caolan McMahon of Kanso, Dale Harvey of PouchDB, Gregor >>>>> Martynus >>>>>>> of Hoodie, just to name a select few) all have similar stories. >>>>> CouchApps >>>>>>> appear genius at first, until you try to build a wide range of things >>>>> with >>>>>>> them. >>>>>>> >>>>>>> At this point, I’m no longer interested what neat things can be done >>>>> with >>>>>>> CouchDB, but I want to make sure we polish the core features as much >>>> as >>>>> we >>>>>>> can so they are easy to understand and use and don’t bring surprises >>>>>>> operationally. >>>>>>> >>>>>>> I don’t mean to kill the concept of CouchApps, but the situation >>>> today >>>>> is >>>>>>> very damaging to our user-adoption rate. I’m more than happy to keep >>>> the >>>>>>> functionality around, because I see there is merit in having it. But >>>>> *most* >>>>>>> CouchDB users I see, shouldn’t not be confused with whatever >>>> “CouchApp” >>>>>>> means when they just want a database that replicates, when they want >>>> to >>>>> put >>>>>>> their data where they need it. >>>>>>> >>>>>>> So yeah, sorry, I don’t think this should be a recruiting vehicle for >>>>>>> CouchDB. >>>>>>> >>>>>>> >>>>>>> Here is a scenario that I can see working: >>>>>>> >>>>>>> 1. establish the idea of applications-in-couchdb as a standalone >>>> project >>>>>>> (can be part of ASF CouchDB) with a name that doesn’t have “couch” in >>>>> it. >>>>>>> >>>>>> >>>>>> yes - but I don't understand why we can't keep the name CouchApp. >>>>> >>>>> My main point here is that “couchapp” is too overloaded as a term and >>>>> really hard to change the meaning of, or reduce the meaning of to that >>>>> one specific thing that we want it to be. >>>>> >>>>> And even *if* CouchApp could just mean “the concept of having apps in >>>>> your CouchDB”, it’d still confuse those users, that think that’s the >>>>> only way to use CouchDB and they walk away. >>>>> >>>> >>>> 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 <j...@b2w.com> wrote: >>>>>>>> >>>>>>>> Cudos to Giovanni for CouchApp enthusiasm >>>>>>>> and to Ermouth for harsh critisim >>>>>>>> to Jan and Andy for addressing the “story” level >>>>>>>> >>>>>>>> In spite of its many shortcomings, I still believe couchApps could >>>> be >>>>>>> the big recruiter for CouchDB. >>>>>>>> The fact that you can make a design document, direct a vhost to its >>>>>>> _rewrite and there create your api for accessing multiple databases >>>> with >>>>>>> various access levels and multiple design documents is awesome. >>>>>>>> >>>>>>>> The main storytelling problem is the overselling as Ermouth points >>>> out. >>>>>>>> The overselling starts with the name itself, it should not have >>>> “app” >>>>> in >>>>>>> it. >>>>>>>> >>>>>>>> The concept of a CouchDB app is wrong. >>>>>>>> The “app” that a million young developers are waiting to create >>>> lives >>>>> in >>>>>>> the client. >>>>>>>> They need to learn some CSS and a Javascript framework, and CouchDB >>>> is >>>>>>> the only backend they will need until they find out that they need >>>> more >>>>> in >>>>>>> addition to CouchDB. >>>>>>>> >>>>>>>> We should quit telling the story about CouchApps and start telling >>>> the >>>>>>> story of design docs. >>>>>>>> CouchDB design documents are great. >>>>>>>> At least as long as we keep it simple. >>>>>>>> >>>>>>>> Our quest should be for powerful simplicity. >>>>>>>> Simplicity always win. >>>>>>>> >>>>>>>> Johs >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On 05 May 2015, at 11:49, Jan Lehnardt <j...@apache.org> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 05 May 2015, at 11:08, Andy Wenk <andyw...@apache.org> wrote: >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Jan thanks for raising this important topic! >>>>>>>>>> >>>>>>>>>> As I had been around and participated when JChris, Jan and others >>>>>>> started >>>>>>>>>> CouchApps and Benoit took over the work, I am a bit sad, that >>>>> CouchApps >>>>>>>>>> started to confuse people. And yes it is true, they are limited >>>> but >>>>>>> have >>>>>>>>>> their place in the history of CouchDB. Far more, it can easily be >>>>> seen >>>>>>> as >>>>>>>>>> the evolutionary basis for Hoodie and that is a good thing imho. >>>>>>>>>> >>>>>>>>>> We should give CouchApps a place to live in the CouchDB ecosystem >>>>> (not >>>>>>>>>> meant technically). So my proposal is to reactivate couchapp.org >>>> and >>>>>>> write >>>>>>>>>> one page with info about >>>>>>>>>> >>>>>>>>>> * what CouchApps are >>>>>>>>>> * how one can create one (links to doku) >>>>>>>>>> * what alternatives there are (kanso, hoodie ...) >>>>>>>>>> >>>>>>>>>> Furthermore we should include a link on couchdb.org to >>>> couchapp.org. >>>>>>>>>> >>>>>>>>>> I think it would be wrong to leave people still in the dark even >>>>> though >>>>>>>>>> nowadays we think, CouchApps is not the way one should create a >>>>> WebApp >>>>>>>>>> based on CouchDB (and I don't think the approaches to create >>>>> CouchApps >>>>>>> was >>>>>>>>>> foolish Jan ;-)). It is our responsibility to clarify what >>>> CouchApps >>>>>>> are >>>>>>>>>> and why one should move forward to sth. better. With clarification >>>>>>> comes >>>>>>>>>> clarity >>>>>>>>> >>>>>>>>> Thanks Andy! — I’m all for the things you mention, once we figure >>>> out >>>>>>> how >>>>>>>>> the CouchApps story fits into the larger CouchDB story without >>>>> confusing >>>>>>>>> anyone. >>>>>>>>> >>>>>>>>> What’s your take on that? :) >>>>>>>>> >>>>>>>>> * * * >>>>>>>>> >>>>>>>>> Also, I think we shouldn’t be afraid to make CouchApp’s place in >>>>>>> CouchDB’s >>>>>>>>> history clear in terms of “This was an idea of its time. Today, we >>>>> think >>>>>>>>> differently. RIP CouchApps”. >>>>>>>>> >>>>>>>>> >>>>>>>>> Best >>>>>>>>> Jan >>>>>>>>> -- >>>>>>>>> >>>>>>>>>> >>>>>>>>>> All the best >>>>>>>>>> >>>>>>>>>> Andy >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 5 May 2015 at 10:54, Jan Lehnardt <j...@apache.org> wrote: >>>>>>>>>> >>>>>>>>>>> It seems we have a separate discussion going on here, so I forked >>>>> the >>>>>>>>>>> thread. >>>>>>>>>>> >>>>>>>>>>> I’ve seen these two sides ever since we invented CouchApps: >>>>>>>>>>> >>>>>>>>>>> Pro: >>>>>>>>>>> - CouchApps are amazingly simple >>>>>>>>>>> - CouchDB as an app server is a great idea, I don’t need to run >>>> any >>>>>>> other >>>>>>>>>>> infrastructure >>>>>>>>>>> - this is the future of web development >>>>>>>>>>> - couchapp* is a great tool to manage design docs >>>>>>>>>>> >>>>>>>>>>> (*or erica… etc.) >>>>>>>>>>> >>>>>>>>>>> Con: >>>>>>>>>>> - the concept of compiling design docs is confusing >>>>>>>>>>> - even when they get it, they are confused that they need a third >>>>>>> party >>>>>>>>>>> tool called `couchapp` to do so, because the documentation talks >>>>> about >>>>>>>>>>> building full apps in CouchDB, they have an external app and just >>>>>>> want to >>>>>>>>>>> use CouchDB as a database, but couchapp is still the tool they >>>> need. >>>>>>>>>>> - the tooling is poor >>>>>>>>>>> - the tooling is all third-party >>>>>>>>>>> - they can only cover a very limited use-case >>>>>>>>>>> - CouchApps are the only way to use CouchDB >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I see a number of people being passionate about CouchApps and I >>>>>>> believe >>>>>>>>>>> their enthusiasm is warranted, CouchApps are a neat idea. >>>>>>>>>>> >>>>>>>>>>> But I also see a greater number of people being confused by >>>>> CouchApps >>>>>>> and >>>>>>>>>>> in turn by CouchDB. >>>>>>>>>>> >>>>>>>>>>> That is not a good situation. >>>>>>>>>>> >>>>>>>>>>> Let’s think about how (and if) we can fit the CouchApp story >>>> into a >>>>>>>>>>> coherent CouchDB story. >>>>>>>>>>> >>>>>>>>>>> A prerequisite for that is having a coherent CouchDB story, >>>> which we >>>>>>> don’t >>>>>>>>>>> have fully finalised yet, but we have talked about extensively, >>>> and >>>>>>> the >>>>>>>>>>> consensus is around the “Data where you need it” narrative that >>>>>>> emphasises >>>>>>>>>>> replication between CouchDB instances and other projects that >>>> speak >>>>>>> the >>>>>>>>>>> replication protocol (especially PouchDB and TouchDB). >>>>>>>>>>> >>>>>>>>>>> How do CouchApps fit into that narrative? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> * * * >>>>>>>>>>> >>>>>>>>>>> (Personal view alert: this is just to give some more background >>>> on >>>>> my >>>>>>> own >>>>>>>>>>> position, this isn’t meant as a basis for discussion) >>>>>>>>>>> >>>>>>>>>>> I’m personally conflicted. When we set out to develop CouchApps, >>>> we >>>>>>>>>>> thought we are inventing a new paradigm for how to build the web, >>>>> and >>>>>>>>>>> everybody would follow us, because that would enable a true p2p >>>> web. >>>>>>> That >>>>>>>>>>> didn’t happen and probably was a little foolish of us :D >>>>>>>>>>> >>>>>>>>>>> Technically, that would have meant CouchApps had to grow a lot >>>> more >>>>>>> and I >>>>>>>>>>> realised quickly that CouchDB is not the right place to grow >>>> such a >>>>>>> thing. >>>>>>>>>>> In addition, there are various fully fledged web frameworks >>>> already >>>>>>> and >>>>>>>>>>> CouchApps could never really compete in terms of person-power and >>>>>>> attention. >>>>>>>>>>> >>>>>>>>>>> That all led me to re-evaluate the whole value proposition, when >>>>>>> things >>>>>>>>>>> like PouchDB came up and the browser became a decent application >>>>>>>>>>> development platform. That whole thinking led to the creation of >>>>>>> Hoodie ( >>>>>>>>>>> http://hood.ie), which started out with the code name CANG >>>> (Couch >>>>>>> Apps >>>>>>>>>>> Next Generation), where we liked some of the core ideas of >>>>> CouchApps, >>>>>>> but >>>>>>>>>>> wanted to address the limitations that would stifle their >>>> adoption. >>>>>>> Hoodie >>>>>>>>>>> embraces browser-to-server sync to allow fully offline apps, it >>>>> allows >>>>>>>>>>> all-javascript-all-json development on the front- and back-end. >>>> It >>>>>>> uses the >>>>>>>>>>> database-per-user and the _changes-feed-as-async-worker paradigms >>>>> and >>>>>>> it is >>>>>>>>>>> all wrapped into a package that is *really* easy to understand >>>> and >>>>> get >>>>>>>>>>> started with. Hoodie, unlike CouchApps, does have a fighting >>>> chance >>>>> of >>>>>>>>>>> making CouchDB’s unique features (replication, _changes) >>>> available >>>>>>> for a >>>>>>>>>>> larger population and I’m infinitely excited about that. >>>>>>>>>>> >>>>>>>>>>> * * * >>>>>>>>>>> >>>>>>>>>>> All that doesn’t mean, however, that CouchApps don’t have their >>>>>>> place, but >>>>>>>>>>> again, I’m not sure where that place is and the place it >>>> currently >>>>> has >>>>>>>>>>> seems to negatively affect CouchDB, so I’d like for this list to >>>>>>> think and >>>>>>>>>>> talk about all that for a bit. >>>>>>>>>>> >>>>>>>>>>> How can we make it that CouchApps strengthen CouchDB and not >>>> weaken >>>>>>> it by >>>>>>>>>>> adding confusion? >>>>>>>>>>> >>>>>>>>>>> How do CouchApps fit into the CouchDB story? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Best >>>>>>>>>>> Jan >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On 05 May 2015, at 08:45, ermouth <ermo...@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> CouchDB-killing answers >>>>>>>>>>>> >>>>>>>>>>>> Well... When someone says couchapps is silver bullet – I say >>>> ‘No’ >>>>>>> and I >>>>>>>>>>> can >>>>>>>>>>>> prove it. Couchapps have a lot, A LOT of problems, and some of >>>> them >>>>>>> can >>>>>>>>>>> not >>>>>>>>>>>> be solved inside CouchDB. For example, try to implement ACL for >>>>>>>>>>> attachments >>>>>>>>>>>> or try to scale couchapp. You just can‘t do it in reasonable >>>> way. >>>>>>>>>>>> >>>>>>>>>>>> I know several engineers who tried out couchapps – and left >>>> CouchDB >>>>>>>>>>>> forever. Not because CouchDB itself, but because couchapps. >>>>> O‘Reilly >>>>>>> said >>>>>>>>>>>> it‘s a silver bullet, others said – and what we have? Sloppy and >>>>>>>>>>>> hard-to-debug architecture, that does not scale, has no tooling >>>> and >>>>>>> a lot >>>>>>>>>>>> of security issues. >>>>>>>>>>>> >>>>>>>>>>>> You gonna solve architecture problems with positive posts? >>>>>>>>>>>> >>>>>>>>>>>> What I want to say – there is no need to lie and say couchapps >>>> are >>>>>>> great. >>>>>>>>>>>> Because they are not. >>>>>>>>>>>> >>>>>>>>>>>>> would you like to write down some of your positive:-)) >>>>> experiences? >>>>>>>>>>>> >>>>>>>>>>>> http://ermouth.livejournal.com/tag/couchdb – sorry, Russian >>>>>>> language. >>>>>>>>>>>> >>>>>>>>>>>> ermouth >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Professional Support for Apache CouchDB: >>>>>>>>>>> http://www.neighbourhood.ie/couchdb-support/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Andy Wenk >>>>>>>>>> Hamburg - Germany >>>>>>>>>> RockIt! >>>>>>>>>> >>>>>>>>>> GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588 >>>>>>>>>> >>>>>>>>>> https://people.apache.org/keys/committer/andywenk.asc >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Professional Support for Apache CouchDB: >>>>>>>>> http://www.neighbourhood.ie/couchdb-support/< >>>>>>> http://www.neighbourhood.ie/couchdb-support/> >>>>>>> >>>>>>> -- >>>>>>> Professional Support for Apache CouchDB: >>>>>>> http://www.neighbourhood.ie/couchdb-support/ >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Andy Wenk >>>>>> Hamburg - Germany >>>>>> RockIt! >>>>>> >>>>>> GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588 >>>>>> >>>>>> https://people.apache.org/keys/committer/andywenk.asc >>>>> >>>>> -- >>>>> Professional Support for Apache CouchDB: >>>>> http://www.neighbourhood.ie/couchdb-support/ >>>>> >>>>> >>>> >>>> >>>> -- >>>> 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/ -- Professional Support for Apache CouchDB: http://www.neighbourhood.ie/couchdb-support/
