Return-Path: X-Original-To: apmail-couchdb-marketing-archive@minotaur.apache.org Delivered-To: apmail-couchdb-marketing-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4031A17A5A for ; Thu, 7 May 2015 16:34:11 +0000 (UTC) Received: (qmail 805 invoked by uid 500); 7 May 2015 16:34:11 -0000 Delivered-To: apmail-couchdb-marketing-archive@couchdb.apache.org Received: (qmail 774 invoked by uid 500); 7 May 2015 16:34:11 -0000 Mailing-List: contact marketing-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: marketing@couchdb.apache.org Delivered-To: mailing list marketing@couchdb.apache.org Received: (qmail 753 invoked by uid 99); 7 May 2015 16:34:10 -0000 Received: from Unknown (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 07 May 2015 16:34:10 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 50C55C092D for ; Thu, 7 May 2015 16:34:10 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 4.001 X-Spam-Level: **** X-Spam-Status: No, score=4.001 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=3, KAM_LAZY_DOMAIN_SECURITY=1, URIBL_BLOCKED=0.001] autolearn=disabled Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id AApngQwoF00D for ; Thu, 7 May 2015 16:33:54 +0000 (UTC) Received: from smtpcmd02111.aruba.it (smtpcmd02111.aruba.it [62.149.158.111]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTP id AAA902314B for ; Thu, 7 May 2015 16:33:53 +0000 (UTC) Received: from mail-ie0-f172.google.com ([209.85.223.172]) by smtpcmd02.ad.aruba.it with bizsmtp id R4Xp1q01C3jnPnV014Xqnu; Thu, 07 May 2015 18:31:51 +0200 Received: by ieczm2 with SMTP id zm2so43667318iec.2 for ; Thu, 07 May 2015 09:31:49 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.138.130 with SMTP id c2mr5815577ioj.74.1431016309847; Thu, 07 May 2015 09:31:49 -0700 (PDT) Received: by 10.107.57.193 with HTTP; Thu, 7 May 2015 09:31:49 -0700 (PDT) In-Reply-To: <554B8E49.5030102@meetinghouse.net> References: <554B7F4E.6030800@meetinghouse.net> <554B8E49.5030102@meetinghouse.net> Date: Thu, 7 May 2015 18:31:49 +0200 Message-ID: Subject: Re: Re: the future of couchapp From: Giovanni Lenzi To: marketing@couchdb.apache.org Content-Type: multipart/alternative; boundary=001a113f284ed121b9051580724c --001a113f284ed121b9051580724c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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=3D#query:%20list%3Aorg.apache.couchdb= .marketing+page:8+mid:zaty7v63giukyykh+state:results 2015-05-07 18:09 GMT+02:00 Miles Fidelman : > 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 CouchApp= s" >> 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 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-Stor= y. >>> >>> In >>> >>> http://markmail.org/message/no3jfksdxjcgxz4d >>> >>> you personally said: >>> "Technically, that would have meant CouchApps had to grow a lot more an= d >>> 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 databas= e >>> 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 =E2=80=9CCouchApp=E2=80=9D" >>> >>> Sorry this words are not misunderstandable for me. And I am wondering w= hy >>> 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 everywher= e >>> 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 ta= ke >>> 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 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 wrote: >>>>> >>>>> Sorry guys, my eyes dont believe what they see.. >>>>> @Jan: How are you? long time not spoken to eachother. How is Lena? Wh= at >>>>> >>>> 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 i= t? >>>>> >>>>> 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 i= n >>>>> >>>> 2010 >>>> >>>>> and never improved. >>>>> >>>>> We should not forget what CouchDB is all about. And for me the guys w= ho >>>>> claim out to remove couchapp simply forget the power Damien have buil= t >>>>> 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 previous= ly >>>>> business standard groupware software for large scale companies before >>>>> SAP >>>>> was destroying it's reputations with the help of IBM (which wanted on= ly >>>>> >>>> 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 S= AP >>>>> 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 fe= ar >>>>> >>>> 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 abo= ut >>>>> >>>> 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 i= t >>>>> 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 an= d >>>>> >>>> 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 nam= e >>>>> >>>>> What you all think about it? >>>>> >>>>> >>>>> 2015-05-05 22:35 GMT+02:00 Giovanni Lenzi : >>>>> >>>>> 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 change= d >>>>>> 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 wha= t >>>>>> 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" ha >>>>>> >>>>> scritto: >>>> >>>>> On 5 May 2015 at 18:44, Jan Lehnardt wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 05 May 2015, at 18:37, Andy Wenk 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 m= e. >>>>>>>>> >>>>>>>> Here >>>>>>> >>>>>>>> are my comments: >>>>>>>>> >>>>>>>>> On 5 May 2015 at 17:39, Jan Lehnardt 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=E2=80=99ll 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 =E2=80=9Ccompile JS= into >>>>>>>>>> >>>>>>>>> JSON >>>>>>> >>>>>>>> into >>>>>>>> >>>>>>>>> a doc with a weird name=E2=80=9D. 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=E2=80=99s still design docs, = but the >>>>>>>>>> >>>>>>>>> interface >>>>>>>> >>>>>>>>> would be A LOT more friendly. >>>>>>>>>> >>>>>>>>>> With 2.0 and Mango I=E2=80=99d hope that 90% of our users don=E2= =80=99t have to >>>>>>>>>> >>>>>>>>> touch >>>>> >>>>>> ddocs anymore for basic CouchDB querying. I=E2=80=99d 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=E2=80=99d be less ne= ed 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 problem= s, >>>>>>>>>> >>>>>>>>> see >>>>>>> >>>>>>>> above) >>>>>>>>>> - the second thing people get to hear, when they ask about how d= o >>>>>>>>>> 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 performan= ce >>>>>>>>>> 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=E2=80=99s story-of-couchapp = email. >>>>>>>>>> I=E2=80=99ve >>>>>>>>>> >>>>>>>>> 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=E2=80=99m 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=E2=80=99t brin= g >>>>>>>>>> surprises >>>>>>>>>> operationally. >>>>>>>>>> >>>>>>>>>> I don=E2=80=99t mean to kill the concept of CouchApps, but the s= ituation >>>>>>>>>> >>>>>>>>> today >>>>>>> >>>>>>>> is >>>>>>>> >>>>>>>>> very damaging to our user-adoption rate. I=E2=80=99m more than ha= ppy to >>>>>>>>>> keep >>>>>>>>>> >>>>>>>>> the >>>>>>> >>>>>>>> functionality around, because I see there is merit in having it. B= ut >>>>>>>>>> >>>>>>>>> *most* >>>>>>>> >>>>>>>>> CouchDB users I see, shouldn=E2=80=99t not be confused with whate= ver >>>>>>>>>> >>>>>>>>> =E2=80=9CCouchApp=E2=80=9D >>>>>>> >>>>>>>> means when they just want a database that replicates, when they wa= nt >>>>>>>>>> >>>>>>>>> to >>>>>>> >>>>>>>> put >>>>>>>> >>>>>>>>> their data where they need it. >>>>>>>>>> >>>>>>>>>> So yeah, sorry, I don=E2=80=99t think this should be a recruitin= g 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=E2=80=99t have= =E2=80=9Ccouch=E2=80=9D >>>>>>>>>> >>>>>>>>> in >>>>> >>>>>> it. >>>>>>>> >>>>>>>>> yes - but I don't understand why we can't keep the name CouchApp. >>>>>>>>> >>>>>>>> My main point here is that =E2=80=9Ccouchapp=E2=80=9D is too overl= oaded 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 =E2=80=9Cthe concept of hav= ing apps >>>>>>>> in >>>>>>>> your CouchDB=E2=80=9D, it=E2=80=99d still confuse those users, tha= t think that=E2=80=99s 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 y= ou >>>>>>> >>>>>> are >>>> >>>>> way more in contact with users, I take it for granted. >>>>>>> >>>>>>> >>>>>>> I don=E2=80=99t think CouchApps 2.0 is going to help. Especially w= ith >>>>>>>> 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=E2=80=99t 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 momen= t >>>>>>> >>>>>> and >>>> >>>>> I >>>>> >>>>>> don't insist on it. If we find the common consensus that we should l= et >>>>>>> >>>>>> 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=E2=80=99t= need >>>>>>>>>> extra >>>>>>>>>> tooling with CouchDB (maybe a little bit like couchdb-cli that >>>>>>>>>> >>>>>>>>> rkowalski is >>>>>>>> >>>>>>>>> toying with, but we=E2=80=99d 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 impleme= nt >>>>>>>>>> >>>>>>>>> e.g. >>>>>>> >>>>>>>> more efficient list functions. >>>>>>>>>> >>>>>>>>> yes >>>>>>>>> >>>>>>>>> >>>>>>>>> 4. publicly celebrate the retirement of all things =E2=80=9CCouc= hApp=E2=80=9D with >>>>>>>>>> pointers on couchapp.org/.com to where the things =E2=80=9CCouch= Apps=E2=80=9D >>>>>>>>>> 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 tha= t >>>>>>>>>> >>>>>>>>> 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 h= ad >>>>>>>>> >>>>>>>> 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 a= nd >>>>>>>>> >>>>>>>> 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 gi= ve >>>>>>>>> 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 o= wn >>>>>>>>>> >>>>>>>>> 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 Couch= DB >>>>>>>>>> >>>>>>>>> and >>>>>>> >>>>>>>> see where we run into diminishing returns. It took me more than ha= lf >>>>>>>>>> >>>>>>>>> a >>>>>>> >>>>>>>> decade to learn that CouchApps harm CouchDB more than they help. W= e >>>>>>>>>> >>>>>>>>> as >>>>>>> >>>>>>>> the >>>>>>>> >>>>>>>>> project shouldn=E2=80=99t 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 =E2=80=9Cbut but but CouchApps are = cool=E2=80=A6=E2=80=9D >>>>>>>>>> >>>>>>>>> type. I >>>>>>> >>>>>>>> understand. I think they are cool too. >>>>>>>>>> >>>>>>>>>> Best >>>>>>>>>> Jan >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 05 May 2015, at 16:52, Johs Ensby wrote: >>>>>>>>>>> >>>>>>>>>>> Cudos to Giovanni for CouchApp enthusiasm >>>>>>>>>>> and to Ermouth for harsh critisim >>>>>>>>>>> to Jan and Andy for addressing the =E2=80=9Cstory=E2=80=9D leve= l >>>>>>>>>>> >>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>> =E2=80=9Capp=E2=80=9D >>>>>>> >>>>>>>> in >>>>>>>> >>>>>>>>> it. >>>>>>>>>> >>>>>>>>>>> The concept of a CouchDB app is wrong. >>>>>>>>>>> The =E2=80=9Capp=E2=80=9D that a million young developers are w= aiting 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 >>>>>>>>>>>> >>>>>>>>>>> wrote: >>>>> >>>>>> On 05 May 2015, at 11:08, Andy Wenk >>>>>>>>>>>>> >>>>>>>>>>>> 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! =E2=80=94 I=E2=80=99m all for the things you ment= ion, once >>>>>>>>>>>> >>>>>>>>>>> we figure >>>>> >>>>>> out >>>>>>> >>>>>>>> how >>>>>>>>>> >>>>>>>>>>> the CouchApps story fits into the larger CouchDB story without >>>>>>>>>>>> >>>>>>>>>>> confusing >>>>>>>> >>>>>>>>> anyone. >>>>>>>>>>>> >>>>>>>>>>>> What=E2=80=99s your take on that? :) >>>>>>>>>>>> >>>>>>>>>>>> * * * >>>>>>>>>>>> >>>>>>>>>>>> Also, I think we shouldn=E2=80=99t be afraid to make CouchApp= =E2=80=99s >>>>>>>>>>>> >>>>>>>>>>> place in >>>>> >>>>>> CouchDB=E2=80=99s >>>>>>>>>> >>>>>>>>>>> history clear in terms of =E2=80=9CThis was an idea of its time= . >>>>>>>>>>>> >>>>>>>>>>> Today, we >>>>> >>>>>> think >>>>>>>> >>>>>>>>> differently. RIP CouchApps=E2=80=9D. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Best >>>>>>>>>>>> Jan >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> All the best >>>>>>>>>>>>> >>>>>>>>>>>>> Andy >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 5 May 2015 at 10:54, Jan Lehnardt >>>>>>>>>>>>> >>>>>>>>>>>> wrote: >>>>> >>>>>> It seems we have a separate discussion going on here, >>>>>>>>>>>>>> >>>>>>>>>>>>> so I forked >>>>> >>>>>> the >>>>>>>> >>>>>>>>> thread. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I=E2=80=99ve 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=E2=80=99t >>>>>>>>>>>>>> >>>>>>>>>>>>> need to run >>>>> >>>>>> any >>>>>>> >>>>>>>> other >>>>>>>>>> >>>>>>>>>>> infrastructure >>>>>>>>>>>>>> - this is the future of web development >>>>>>>>>>>>>> - couchapp* is a great tool to manage design docs >>>>>>>>>>>>>> >>>>>>>>>>>>>> (*or erica=E2=80=A6 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=E2=80=99s think about how (and if) we can fit the CouchA= pp >>>>>>>>>>>>>> >>>>>>>>>>>>> story >>>>> >>>>>> into a >>>>>>> >>>>>>>> coherent CouchDB story. >>>>>>>>>>>>>> >>>>>>>>>>>>>> A prerequisite for that is having a coherent CouchDB >>>>>>>>>>>>>> >>>>>>>>>>>>> story, >>>>> >>>>>> which we >>>>>>> >>>>>>>> don=E2=80=99t >>>>>>>>>> >>>>>>>>>>> have fully finalised yet, but we have talked about >>>>>>>>>>>>>> >>>>>>>>>>>>> extensively, >>>>> >>>>>> and >>>>>>> >>>>>>>> the >>>>>>>>>> >>>>>>>>>>> consensus is around the =E2=80=9CData where you need it=E2=80= =9D >>>>>>>>>>>>>> >>>>>>>>>>>>> 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=E2=80=99t meant as a basis for discussion) >>>>>>>>>>>>>> >>>>>>>>>>>>>> I=E2=80=99m personally conflicted. When we set out to develo= p >>>>>>>>>>>>>> >>>>>>>>>>>>> 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=E2=80=99t 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 >>>>>>>>>>>>> >>>>>>>>>>>>> --=20 Giovanni Lenzi www.smileupps.com Smileupps Couchapps Store --001a113f284ed121b9051580724c--