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 EFF7A17E29 for ; Wed, 6 May 2015 05:11:04 +0000 (UTC) Received: (qmail 90561 invoked by uid 500); 6 May 2015 05:11:04 -0000 Delivered-To: apmail-couchdb-marketing-archive@couchdb.apache.org Received: (qmail 90526 invoked by uid 500); 6 May 2015 05:11:04 -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 90515 invoked by uid 99); 6 May 2015 05:11:04 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 May 2015 05:11:04 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: unknown ~allinclude:_spf.google.com (athena.apache.org: encountered unrecognized mechanism during SPF processing of domain of johs@b2w.com) Received: from [54.191.145.13] (HELO mx1-us-west.apache.org) (54.191.145.13) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 May 2015 05:10:59 +0000 Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by mx1-us-west.apache.org (ASF Mail Server at mx1-us-west.apache.org) with ESMTPS id 14C6F24E1E for ; Wed, 6 May 2015 05:10:38 +0000 (UTC) Received: by wgin8 with SMTP id n8so204103731wgi.0 for ; Tue, 05 May 2015 22:10:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:to:in-reply-to; bh=T0m5iAPm1+b+zUqS4mi6ohhixSo9cxln39QR9R6S55Q=; b=ZTNjqJhgvO0URUBWuxbVD8A9T+PKcDKqag4bh8sQ7QMujfS9rPkqYTyQWo9vU2oxBE Zazald8S+FXnrQRSZ6QgFE3g+C0cJJTnxeVZQh5hgzPHXqow4ijFX3jAObC8udYBdpiD 9qVq644S2GWw7vFw2kkBmiNjQ9BlBlFRa0EYUj7pwZcE3hzMAjhxrwaqUHVWIqQ+9qY+ qRFFYxgp4Hfj77XCBqtYnWNJF5Jeyhx6f6cSzA6IHDX03Cp+myLMu8HaasTTGuPI9vD9 64RvrcKXFBFrBynXKNXUoD0SMiT7Y1LdRu+oMC8QHpCPI+UCq9QzVPghdV9HUOaCi/iE mmHw== X-Gm-Message-State: ALoCoQlTtF/eMo/IDzpfcKV+er7ROIrmVMeBFx4fbGo/X+LgN0JHCapgBIVHW2jBltnOsmLURzYe X-Received: by 10.180.74.208 with SMTP id w16mr1452638wiv.31.1430889036581; Tue, 05 May 2015 22:10:36 -0700 (PDT) Received: from [192.168.2.4] ([82.147.57.124]) by mx.google.com with ESMTPSA id go4sm310766wib.1.2015.05.05.22.10.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 May 2015 22:10:35 -0700 (PDT) From: Johs Ensby Content-Type: multipart/alternative; boundary="Apple-Mail=_5D91270B-700F-4FA3-B290-948B938283DE" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: How do CouchApps fit into the CouchDB story? (Was: CouchDB Articles, Pills and Tutorials Ideas) Date: Wed, 6 May 2015 07:10:58 +0200 References: <33BD4D82-787C-48D5-B963-FEEA4C0913CB@apache.org> <4209351E-F51E-4DB5-8A5F-8AB53DA21877@apache.org> <0B891CED-B735-4D86-86D2-1C4CDF6BDE21@apache.org> To: marketing@couchdb.apache.org In-Reply-To: X-Mailer: Apple Mail (2.1990.1) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail=_5D91270B-700F-4FA3-B290-948B938283DE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Giovanni, on the issue of the death of CouchApps, I think one opportunity is this: CouchApp is (among all the other things that Jan listed) one or a set of = design documents=20 We have 2 names for the same thing, approximately My suggestion is to start using ddocs, design docs or design documents = and let CouchApp fade out by itself, no killing needed Jan, I like the suggestion to separate CouchApps into a separate project. = That should start with A defined target group Clear design goals A rigid plugin architecture=20 The idea that I find very powerful is Let the functionality follow the data Databases have had stored procedures for ages, but what database = provided a methodology for letting functionality piggyback the data as = easily as in CouchDB? Could there be a sweet spot between =E2=80=9Cconvenience = functionality=E2=80=9D for advanced developers and what would be = attractive to novice developers and developers looking for a = minimalistic tech stack? Thanks for listing the pioneers, Jan. Would anyone care to complete the = list of people that took CouchApps to the extreme and would be good = candidates for a roundtable on design goals for its future? Caolan McMahon of Kanso @caolan Dale Harvey of PouchDB @daleharvey Gregor Martynus of Hoodie @einfachsmart = Ermouth of Cloudwall @ermouth =20 Giovanni of Smileupps @smileupps Johs > On 05 May 2015, at 22:35, Giovanni Lenzi = wrote: >=20 > Agree with Andy.. why change a name of something that is born with = couchdb, > lives in couchdb and runs only inside of it? >=20 > 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... >=20 > 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 >=20 > 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 >=20 > 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" ha = scritto: >=20 >> On 5 May 2015 at 18:44, Jan Lehnardt wrote: >>=20 >>>=20 >>>> On 05 May 2015, at 18:37, Andy Wenk wrote: >>>>=20 >>>> 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: >>>>=20 >>>> On 5 May 2015 at 17:39, Jan Lehnardt wrote: >>>>=20 >>>>> Thanks for bringing up naming and design docs! >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> With 2.0 and Mango I=E2=80=99d hope that 90% of our users don=E2=80=99= t 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. >>>>>=20 >>>>> (See, now this turns into a future-of-couchdb discussion, sorry = about >>>>> that). >>>>>=20 >>>>> With nice APIs for all core features, there=E2=80=99d be less need = for a tool >>> that >>>>> manages design docs. >>>>>=20 >>>>> What CouchApps can *do* today, would, however, still be possible. >>>>>=20 >>>>> Which brings me to naming. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> This is very very very very confusing and we need to clean it up. >>>>>=20 >>>>> * * * >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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 bring = surprises >>>>> operationally. >>>>>=20 >>>>> I don=E2=80=99t mean to kill the concept of CouchApps, but the = situation today >>> is >>>>> very damaging to our user-adoption rate. I=E2=80=99m more than = happy to keep >> the >>>>> functionality around, because I see there is merit in having it. = But >>> *most* >>>>> CouchDB users I see, shouldn=E2=80=99t not be confused with = whatever >> =E2=80=9CCouchApp=E2=80=9D >>>>> means when they just want a database that replicates, when they = want >> to >>> put >>>>> their data where they need it. >>>>>=20 >>>>> So yeah, sorry, I don=E2=80=99t think this should be a recruiting = vehicle for >>>>> CouchDB. >>>>>=20 >>>>>=20 >>>>> Here is a scenario that I can see working: >>>>>=20 >>>>> 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. >>>>>=20 >>>>=20 >>>> yes - but I don't understand why we can't keep the name CouchApp. >>>=20 >>> My main point here is that =E2=80=9Ccouchapp=E2=80=9D 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. >>>=20 >>> And even *if* CouchApp could just mean =E2=80=9Cthe concept of = having apps in >>> your CouchDB=E2=80=9D, it=E2=80=99d still confuse those users, that = think that=E2=80=99s the >>> only way to use CouchDB and they walk away. >>>=20 >>=20 >> 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. >>=20 >>=20 >>> I don=E2=80=99t think CouchApps 2.0 is going to help. Especially = with CouchDB >>> 2.0 coming up, I see even more confusion and less clarity. >>>=20 >>=20 >> 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'). >>=20 >>=20 >>>> We have that name and we have a domain for it. >>>=20 >>> 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. >>>=20 >>=20 >> 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. >>=20 >> All the best >>=20 >> Andy >>=20 >>>=20 >>> Thanks for your support on the other points. >>>=20 >>> Best >>> Jan >>> -- >>>=20 >>>=20 >>>=20 >>>=20 >>>> 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. >>>>=20 >>>>=20 >>>>> 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) >>>>>=20 >>>>=20 >>>> yes >>>>=20 >>>>=20 >>>>> 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. >>>>>=20 >>>>=20 >>>> yes >>>>=20 >>>>=20 >>>>> 4. publicly celebrate the retirement of all things =E2=80=9CCouchApp= =E2=80=9D with >>>>> pointers on couchapp.org/.com to where the things =E2=80=9CCouchApps= =E2=80=9D were >> used >>>>> for are available now, without confusion. >>>>>=20 >>>>> 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. >>>>>=20 >>>>=20 >>>> 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: >>>>=20 >>>> - In 1.x some parts of the CouchDB API were too complicated, we had = to >>> have >>>> a tool for it. >>>>=20 >>>> - The tool also allowed to build standalone web applications that >> solely >>>> live in CouchDB called a CouchApp. >>>>=20 >>>> - We realised that this approach was resulting in some problems and >>> decided >>>> to move them out of CouchDB. >>>>=20 >>>> - All this is now available as (e.g.) Plugins at couchapp.org and = is >>> called >>>> CouchApp 2.0 >>>>=20 >>>> - We had a good idea, learned and decided that it is better to give >>>> CouchApps it's own environment >>>>=20 >>>> 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). >>>>=20 >>>> Thoughts? >>>>=20 >>>> Cheers >>>>=20 >>>> Andy >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>>=20 >>>>> * * * >>>>>=20 >>>>> 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. >>>>>=20 >>>>> * * * >>>>>=20 >>>>> 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=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. >>>>>=20 >>>>> * * * >>>>>=20 >>>>> 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. >>>>>=20 >>>>> Best >>>>> Jan >>>>> -- >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On 05 May 2015, at 16:52, Johs Ensby wrote: >>>>>>=20 >>>>>> 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 level >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> The concept of a CouchDB app is wrong. >>>>>> The =E2=80=9Capp=E2=80=9D 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. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> Our quest should be for powerful simplicity. >>>>>> Simplicity always win. >>>>>>=20 >>>>>> Johs >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> On 05 May 2015, at 11:49, Jan Lehnardt wrote: >>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 05 May 2015, at 11:08, Andy Wenk = wrote: >>>>>>>>=20 >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> Jan thanks for raising this important topic! >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> 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 >>>>>>>>=20 >>>>>>>> * what CouchApps are >>>>>>>> * how one can create one (links to doku) >>>>>>>> * what alternatives there are (kanso, hoodie ...) >>>>>>>>=20 >>>>>>>> Furthermore we should include a link on couchdb.org to >> couchapp.org. >>>>>>>>=20 >>>>>>>> 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 >>>>>>>=20 >>>>>>> Thanks Andy! =E2=80=94 I=E2=80=99m all for the things you = mention, once we figure >> out >>>>> how >>>>>>> the CouchApps story fits into the larger CouchDB story without >>> confusing >>>>>>> anyone. >>>>>>>=20 >>>>>>> What=E2=80=99s your take on that? :) >>>>>>>=20 >>>>>>> * * * >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>>=20 >>>>>>> Best >>>>>>> Jan >>>>>>> -- >>>>>>>=20 >>>>>>>>=20 >>>>>>>> All the best >>>>>>>>=20 >>>>>>>> Andy >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 5 May 2015 at 10:54, Jan Lehnardt wrote: >>>>>>>>=20 >>>>>>>>> It seems we have a separate discussion going on here, so I = forked >>> the >>>>>>>>> thread. >>>>>>>>>=20 >>>>>>>>> I=E2=80=99ve seen these two sides ever since we invented = CouchApps: >>>>>>>>>=20 >>>>>>>>> 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 >>>>>>>>>=20 >>>>>>>>> (*or erica=E2=80=A6 etc.) >>>>>>>>>=20 >>>>>>>>> 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 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I see a number of people being passionate about CouchApps and = I >>>>> believe >>>>>>>>> their enthusiasm is warranted, CouchApps are a neat idea. >>>>>>>>>=20 >>>>>>>>> But I also see a greater number of people being confused by >>> CouchApps >>>>> and >>>>>>>>> in turn by CouchDB. >>>>>>>>>=20 >>>>>>>>> That is not a good situation. >>>>>>>>>=20 >>>>>>>>> Let=E2=80=99s think about how (and if) we can fit the CouchApp = story into >> a >>>>>>>>> coherent CouchDB story. >>>>>>>>>=20 >>>>>>>>> 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). >>>>>>>>>=20 >>>>>>>>> How do CouchApps fit into that narrative? >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> * * * >>>>>>>>>=20 >>>>>>>>> (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) >>>>>>>>>=20 >>>>>>>>> I=E2=80=99m 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=E2=80=99t happen and probably was a little foolish of us = :D >>>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>>=20 >>>>>>>>> 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=E2=80=99s unique features (replication, = _changes) available >>>>> for a >>>>>>>>> larger population and I=E2=80=99m infinitely excited about = that. >>>>>>>>>=20 >>>>>>>>> * * * >>>>>>>>>=20 >>>>>>>>> All that doesn=E2=80=99t mean, however, that CouchApps don=E2=80= =99t have their >>>>> place, but >>>>>>>>> again, I=E2=80=99m not sure where that place is and the place = it currently >>> has >>>>>>>>> seems to negatively affect CouchDB, so I=E2=80=99d like for = this list to >>>>> think and >>>>>>>>> talk about all that for a bit. >>>>>>>>>=20 >>>>>>>>> How can we make it that CouchApps strengthen CouchDB and not >> weaken >>>>> it by >>>>>>>>> adding confusion? >>>>>>>>>=20 >>>>>>>>> How do CouchApps fit into the CouchDB story? >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Best >>>>>>>>> Jan >>>>>>>>> -- >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> On 05 May 2015, at 08:45, ermouth wrote: >>>>>>>>>>=20 >>>>>>>>>>> CouchDB-killing answers >>>>>>>>>>=20 >>>>>>>>>> Well... When someone says couchapps is silver bullet =E2=80=93 = I say =E2=80=98No=E2=80=99 >>>>> 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=E2=80=98t do it in = reasonable way. >>>>>>>>>>=20 >>>>>>>>>> I know several engineers who tried out couchapps =E2=80=93 = and left >> CouchDB >>>>>>>>>> forever. Not because CouchDB itself, but because couchapps. >>> O=E2=80=98Reilly >>>>> said >>>>>>>>>> it=E2=80=98s a silver bullet, others said =E2=80=93 and what = we have? Sloppy and >>>>>>>>>> hard-to-debug architecture, that does not scale, has no = tooling >> and >>>>> a lot >>>>>>>>>> of security issues. >>>>>>>>>>=20 >>>>>>>>>> You gonna solve architecture problems with positive posts? >>>>>>>>>>=20 >>>>>>>>>> What I want to say =E2=80=93 there is no need to lie and say = couchapps >> are >>>>> great. >>>>>>>>>> Because they are not. >>>>>>>>>>=20 >>>>>>>>>>> would you like to write down some of your positive:-)) >>> experiences? >>>>>>>>>>=20 >>>>>>>>>> http://ermouth.livejournal.com/tag/couchdb =E2=80=93 sorry, = Russian >>>>> language. >>>>>>>>>>=20 >>>>>>>>>> ermouth >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>> Professional Support for Apache CouchDB: >>>>>>>>> http://www.neighbourhood.ie/couchdb-support/ >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -- >>>>>>>> Andy Wenk >>>>>>>> Hamburg - Germany >>>>>>>> RockIt! >>>>>>>>=20 >>>>>>>> GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 = 9588 >>>>>>>>=20 >>>>>>>> https://people.apache.org/keys/committer/andywenk.asc >>>>>>>=20 >>>>>>> -- >>>>>>> Professional Support for Apache CouchDB: >>>>>>> http://www.neighbourhood.ie/couchdb-support/< >>>>> http://www.neighbourhood.ie/couchdb-support/> >>>>>=20 >>>>> -- >>>>> Professional Support for Apache CouchDB: >>>>> http://www.neighbourhood.ie/couchdb-support/ >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> Andy Wenk >>>> Hamburg - Germany >>>> RockIt! >>>>=20 >>>> GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588 >>>>=20 >>>> https://people.apache.org/keys/committer/andywenk.asc >>>=20 >>> -- >>> Professional Support for Apache CouchDB: >>> http://www.neighbourhood.ie/couchdb-support/ >>>=20 >>>=20 >>=20 >>=20 >> -- >> Andy Wenk >> Hamburg - Germany >> RockIt! >>=20 >> GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588 >>=20 >> https://people.apache.org/keys/committer/andywenk.asc >>=20 --Apple-Mail=_5D91270B-700F-4FA3-B290-948B938283DE--