Back on track.. the story for couchdb may be to start refering couchdb with a new term like: "web-app-db server", or engine if you prefer.. where its primary meaning is not "web application" and "db server" but instead: "web server", "app server" and "db server".. As Paul alread said, to me too this is the power of couchdb.
So the new term "web-app-db" may sound weird at first, but I think it's only a matter of telling the users what it is. 2015-05-07 18:31 GMT+02:00 Giovanni Lenzi <[email protected]>: > just fyi... all started from this discussion, where I was trying to > propose a list of ideas to push couchdb marketing: > > > http://couchdb.markmail.org/search/?q=#query:%20list%3Aorg.apache.couchdb.marketing+page:8+mid:zaty7v63giukyykh+state:results > > > 2015-05-07 18:09 GMT+02:00 Miles Fidelman <[email protected]>: > >> originally posted to user@ - reposted here at Jan's request (slightly >> trimmed) >> >> -------- Forwarded Message -------- >> >> 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.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 >>>>>>>>>>>>>> >>>>>>>>>>>>>> > > > -- > Giovanni Lenzi > www.smileupps.com > Smileupps Couchapps Store > -- Giovanni Lenzi www.smileupps.com Smileupps Couchapps Store
