> On 07.05.2015, at 17:05, Miles Fidelman <[email protected]> wrote: > > Speaking as someone who writes proposals for a living, what I find confusing > are terms that sound very clear - such as "retire CouchApps" - that require > digging through lots of distributed materials to find clarification of what > you really mean.
I didn't bring this to user@ for that exact reason. Let's continue this discussion on marketing@. Can you repost your thoughts there? Best Jan -- > > I.e., it's not "CouchApps" that are confusing - it's the verbiage that's > confusing. > > Personally, I'd like to see more language like: > > CouchDB includes application server functionality, that supports both > client-side and server side native applications, which we call CouchApps." > or maybe, > CouchApps are CouchDB's equivalent of Java applets and servelets. > > I think those are pretty clear descriptions of CouchApps, at a conceptual > level. (If not, then maybe CouchApps really are confusing.) > > Miles Fidelman > > > > Jan Lehnardt wrote: >> 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 > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra >
