Mailing-List: contact marketing-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: marketing@couchdb.apache.org
Received-SPF: pass (athena.apache.org: message received from 54.164.171.186
 which is an MX secondary for marketing@couchdb.apache.org)
Message-ID: <554A6426.2010701@netzmerk.com>
Date: Wed, 06 May 2015 20:57:42 +0200
From: =?UTF-8?B?Sm9oYW5uZXMgSsO2cmcgU2NobWlkdA==?= <schmidt@netzmerk.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: marketing@couchdb.apache.org
Subject: Re: How do CouchApps fit into the CouchDB story? (Was: CouchDB
 Articles,
 Pills and Tutorials Ideas)
References: 
 <CAPMhwa44MTikOXegsV=f5fk4bSoLnkk7d+YkLrr-gyZSYSw5Mg@mail.gmail.com>
In-Reply-To: 
 <CAPMhwa44MTikOXegsV=f5fk4bSoLnkk7d+YkLrr-gyZSYSw5Mg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Dear CouchDB fellows,

I feel, like most of you, a strong passion for CouchDB. Since I
started to dig into CouchDB more than five years ago, I engaged more
and more in the CouchDB universe. Ever since I am fascinated and
convinced by the concept of Couchapps and have written plenty of them
and developed tools for composing Couchapps. That being said, I also
had to perceive that the concept of Couchapps and Design Documents
often confuses people. Thats why I agree with Jan that CouchDB should
move towards a clearer system, which is more beginner friendly and
more easy to explain, but still provides all the great special
features, which makes CouchDB so compelling to the advanced users.

Let's keep this discussion focused on how to make CouchDB better.
Nobody wants to remove our beloved shows and lists. This is just an
impulse to open CouchDB to more developers.

Johannes

On 06.05.2015 17:57, Giovanni Lenzi wrote:
> Given the importance of the topic: the future of couchapp... I'm
> moving this from the @marketing 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 <g.lenzi@smileupps.com>:
> 
>> Agree with Andy.. why change a name of something that is born
>> with couchdb, lives in couchdb and runs only inside of it?
>> 
>> Dropping name or removing it won't simply be understood by users
>> and industries already relying on it. imho negative impact could
>> be very high.. and I'm afraid this could really lead to a new
>> second death for the project, after the first one with the damien
>> katz retirement issue...
>> 
>> all of the above can't be justified with only some naming
>> conflicts, even considered that couchapp tools and also couchappy
>> project have changed their name just to prevent it
>> 
>> More than a naming confusion, i'm aware of a lack of
>> clarification about what can and cannot be done, supported by
>> facts, real examples and eventually benchmarks
>> 
>> Furthermore, so far on social networks I have seen more focus on
>> what cannot be done, instead of the contrary.. and I can well
>> understand users can be afraid and confused by this. Il giorno
>> 05/mag/2015 20:33, "Andy Wenk" <andywenk@apache.org> ha scritto:
>> 
>>> On 5 May 2015 at 18:44, Jan Lehnardt <jan@apache.org> wrote:
>>> 
>>>> 
>>>>> On 05 May 2015, at 18:37, Andy Wenk <andywenk@apache.org>
>>>>> wrote:
>>>>> 
>>>>> As often, here are many truths in all the replies. I see
>>>>> myself just jumping in from the side because I don't
>>>>> actually use CouchApps. I
>>> have
>>>>> full respect for people like Giovanni  who want to keep
>>>>> CouchApps
>>>> 'alive'.
>>>>> So I think the plan Jan wrote done can work quite good also
>>>>> for me.
>>> Here
>>>>> are my comments:
>>>>> 
>>>>> On 5 May 2015 at 17:39, Jan Lehnardt <jan@apache.org>
>>>>> wrote:
>>>>> 
>>>>>> Thanks for bringing up naming and design docs!
>>>>>> 
>>>>>> There are a few angles here, that make it harder for me
>>>>>> to think
>>> about
>>>>>> this. I’ll try to spell it all out.
>>>>>> 
>>>>>> Design Docs: The learning curve of design docs is really,
>>>>>> really
>>> steep
>>>> and
>>>>>> the usability is so bad, that we need third-party tools
>>>>>> to work
>>> around
>>>> this.
>>>>>> 
>>>>>> When we met in Boston a couple of years ago, we agreed
>>>>>> that we
>>> should be
>>>>>> addressing this. Mango is the first concrete step into a
>>>>>> future where CouchDB indexing is more of an API and less
>>>>>> of a “compile JS into
>>> JSON
>>>> into
>>>>>> a doc with a weird name”. I believe that this is the way
>>>>>> forward.
>>>>>> 
>>>>>> I think everything that is in a ddoc could equally be
>>>>>> hidden behind
>>> an
>>>> API
>>>>>> like mango does. Under the hood, it’s still design docs,
>>>>>> but the
>>>> interface
>>>>>> would be A LOT more friendly.
>>>>>> 
>>>>>> With 2.0 and Mango I’d hope that 90% of our users don’t
>>>>>> have to touch ddocs anymore for basic CouchDB querying.
>>>>>> I’d love to extend this to document update validations
>>>>>> and filters as well.
>>>>>> 
>>>>>> (See, now this turns into a future-of-couchdb discussion,
>>>>>> sorry about that).
>>>>>> 
>>>>>> With nice APIs for all core features, there’d be less
>>>>>> need for a tool
>>>> that
>>>>>> manages design docs.
>>>>>> 
>>>>>> What CouchApps can *do* today, would, however, still be
>>>>>> possible.
>>>>>> 
>>>>>> Which brings me to naming.
>>>>>> 
>>>>>> CouchApp is: - a python tool - a nodejs tool - is
>>>>>> implemented in the erlang tool erica - is a concept of
>>>>>> how to put a *very specific type of app* into
>>> CouchDB
>>>>>> - a domain couchapp.com/.org - a way to manage design
>>>>>> documents (which have their own problems,
>>> see
>>>>>> above) - the second thing people get to hear, when they
>>>>>> ask about how do I
>>>> query
>>>>>> CouchDB? - a lose collection of features inside CouchDB
>>>>>> that all have
>>> problems:
>>>>>> - rewrite: not flexible enough, web devs expect more
>>>>>> options for
>>> routing
>>>>>> - show/list/update/filter/validate: terrible performance
>>> characteristics
>>>>>> - map/reduce views: complicated (yet powerful), mediocre
>>>>>> performance characteristics - an url slug in our
>>>>>> documentation: 
>>>>>> http://docs.couchdb.org/en/1.6.1/couchapp/ - this creates
>>>>>> an unfortunate hierarchy, yes, all the things in this 
>>>>>> section are parts of the CouchApp idea, but e.g. doc
>>>>>> update
>>> validations
>>>> are
>>>>>> a valid concept even if you need nothing else from the
>>>>>> CouchApp idea.
>>>>>> 
>>>>>> This is very very very very confusing and we need to
>>>>>> clean it up.
>>>>>> 
>>>>>> * * *
>>>>>> 
>>>>>> I very much sympathise with ermouth’s story-of-couchapp
>>>>>> email. I’ve
>>> been
>>>>>> through similar steps and everyone I know who has taken
>>>>>> CouchApps to
>>> an
>>>>>> extreme (Caolan McMahon of Kanso, Dale Harvey of PouchDB,
>>>>>> Gregor
>>>> Martynus
>>>>>> of Hoodie, just to name a select few) all have similar
>>>>>> stories.
>>>> CouchApps
>>>>>> appear genius at first, until you try to build a wide
>>>>>> range of things
>>>> with
>>>>>> them.
>>>>>> 
>>>>>> At this point, I’m no longer interested what neat things
>>>>>> can be done
>>>> with
>>>>>> CouchDB, but I want to make sure we polish the core
>>>>>> features as much
>>> as
>>>> we
>>>>>> can so they are easy to understand and use and don’t
>>>>>> bring surprises operationally.
>>>>>> 
>>>>>> I don’t mean to kill the concept of CouchApps, but the
>>>>>> situation
>>> today
>>>> is
>>>>>> very damaging to our user-adoption rate. I’m more than
>>>>>> happy to keep
>>> the
>>>>>> functionality around, because I see there is merit in
>>>>>> having it. But
>>>> *most*
>>>>>> CouchDB users I see, shouldn’t not be confused with
>>>>>> whatever
>>> “CouchApp”
>>>>>> means when they just want a database that replicates,
>>>>>> when they want
>>> to
>>>> put
>>>>>> their data where they need it.
>>>>>> 
>>>>>> So yeah, sorry, I don’t think this should be a recruiting
>>>>>> vehicle for CouchDB.
>>>>>> 
>>>>>> 
>>>>>> Here is a scenario that I can see working:
>>>>>> 
>>>>>> 1. establish the idea of applications-in-couchdb as a
>>>>>> standalone
>>> project
>>>>>> (can be part of ASF CouchDB) with a name that doesn’t
>>>>>> have “couch” in
>>>> it.
>>>>>> 
>>>>> 
>>>>> yes - but I don't understand why we can't keep the name
>>>>> CouchApp.
>>>> 
>>>> My main point here is that “couchapp” is too overloaded as a
>>>> term and really hard to change the meaning of, or reduce the
>>>> meaning of to that one specific thing that we want it to be.
>>>> 
>>>> And even *if* CouchApp could just mean “the concept of having
>>>> apps in your CouchDB”, it’d still confuse those users, that
>>>> think that’s the only way to use CouchDB and they walk away.
>>>> 
>>> 
>>> To be honest, I am not aware that it is such a big problem but
>>> as you are way more in contact with users, I take it for
>>> granted.
>>> 
>>> 
>>>> I don’t think CouchApps 2.0 is going to help. Especially with
>>>> CouchDB 2.0 coming up, I see even more confusion and less
>>>> clarity.
>>>> 
>>> 
>>> My thought was this: we celebrate both CouchDB 2.0 and CouchApp
>>> 2.0 and hammer as long as needed on the point how we want
>>> CouchApps to be seen. I thought it's a great chance to clearly
>>> separate the two different things when CouchDB 2.0 is released.
>>> But I know it is tremendously difficult to achieve the wanted
>>> result communication wise. Maybe the task is too heavy but I
>>> can remember various projects that said "Since version x.y we 
>>> decided to separate this and that from the main project". But I
>>> also admit that I also remember that it still was needed to
>>> clarify the situation afterwards for some folks ('Why is this
>>> not there anymore?' .... 'They dropped it in 2.0' ... 'Ah ok -
>>> did not know').
>>> 
>>> 
>>>>> We have that name and we have a domain for it.
>>>> 
>>>> I mentioned diminishing returns, just because we invested in
>>>> something that doesn’t mean it makes sense holding on to it
>>>> for the future.
>>>> 
>>> 
>>> sure not ;-). My intention is to keep it so that's the reason
>>> why I promote my idea sustained. But that's the point of view I
>>> have at the moment and I don't insist on it. If we find the
>>> common consensus that we should let the term CouchApp die,
>>> that's ok with me.
>>> 
>>> All the best
>>> 
>>> Andy
>>> 
>>>> 
>>>> Thanks for your support on the other points.
>>>> 
>>>> Best Jan --
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> As I said before, we have to clarify extremely well what
>>>>> the project folks think about CouchApps. I could imagine to
>>>>> let Giovanni work on that page with our support.
>>>>> 
>>>>> 
>>>>>> 2. provide APIs for all design-doc-features, so we don’t
>>>>>> need extra tooling with CouchDB (maybe a little bit like
>>>>>> couchdb-cli that
>>>> rkowalski is
>>>>>> toying with, but we’d ship that with CouchDB)
>>>>>> 
>>>>> 
>>>>> yes
>>>>> 
>>>>> 
>>>>>> 3. Turn all 1.x-level CouchApp features (shows, lists,
>>>>>> updates,
>>> vhosts,
>>>>>> rewrites) into a plugin (can be installed by default, and
>>>>>> maybe later
>>>> not).
>>>>>> The plugin then can evolve independently from CouchDB and
>>>>>> implement
>>> e.g.
>>>>>> more efficient list functions.
>>>>>> 
>>>>> 
>>>>> yes
>>>>> 
>>>>> 
>>>>>> 4. publicly celebrate the retirement of all things
>>>>>> “CouchApp” with pointers on couchapp.org/.com to where
>>>>>> the things “CouchApps” were
>>> used
>>>>>> for are available now, without confusion.
>>>>>> 
>>>>>> The story then is: - In 1.x some parts of the CouchDB API
>>>>>> were too complicated, we had
>>> to
>>>>>> have a tool for it. - The tool also allowed to build
>>>>>> standalone web applications that
>>> solely
>>>>>> live in CouchDB. - All this is now available elsewhere
>>>>>> under these new names: X, Y, Z. - R.I.P. CouchApps.
>>>>>> 
>>>>> 
>>>>> I still don't understand why we have to bury CouchApp, but
>>>>> maybe I am missing some key thoughts here. Imho we could
>>>>> also tell:
>>>>> 
>>>>> - In 1.x some parts of the CouchDB API were too
>>>>> complicated, we had to
>>>> have
>>>>> a tool for it.
>>>>> 
>>>>> - The tool also allowed to build standalone web
>>>>> applications that
>>> solely
>>>>> live in CouchDB called a CouchApp.
>>>>> 
>>>>> - We realised that this approach was resulting in some
>>>>> problems and
>>>> decided
>>>>> to move them out of CouchDB.
>>>>> 
>>>>> - All this is now available as (e.g.) Plugins at
>>>>> couchapp.org and is
>>>> called
>>>>> CouchApp 2.0
>>>>> 
>>>>> - We had a good idea, learned and decided that it is better
>>>>> to give CouchApps it's own environment
>>>>> 
>>>>> TL;DR; we learned form the first attempt and the result is
>>>>> a own place
>>>> for
>>>>> CouchApps. We have the name, we have the domain and what we
>>>>> need is clarification (sorry for repeating myself).
>>>>> 
>>>>> Thoughts?
>>>>> 
>>>>> Cheers
>>>>> 
>>>>> Andy
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> * * *
>>>>>> 
>>>>>> We have talked about focussing the CouchDB message and we
>>>>>> agreed that replication and its ecosystem are the prime
>>>>>> story to tell. I believe CouchApps are a huge distraction
>>>>>> from that story and we should own to retire it.
>>>>>> 
>>>>>> * * *
>>>>>> 
>>>>>> So far my thoughts. I realise people have invested a lot
>>>>>> in
>>> CouchApps (I
>>>>>> know I have for 5+ years), but we have to be looking out
>>>>>> for CouchDB
>>> and
>>>>>> see where we run into diminishing returns. It took me
>>>>>> more than half
>>> a
>>>>>> decade to learn that CouchApps harm CouchDB more than
>>>>>> they help. We
>>> as
>>>> the
>>>>>> project shouldn’t focus on what is technically neat/cool,
>>>>>> but how we
>>> can
>>>>>> get more people to use our project because it fits their
>>>>>> needs and is easily accessible. We have many other fronts
>>>>>> to fight to get this
>>> right,
>>>>>> but with CouchApps, we have a foot firmly on a break when
>>>>>> it comes to making CouchDB more accessible.
>>>>>> 
>>>>>> * * *
>>>>>> 
>>>>>> I know this is a lot to take in. Take your time. You
>>>>>> might want to
>>>> refrain
>>>>>> from knee-jerk-replies of the “but but but CouchApps are
>>>>>> cool…”
>>> type. I
>>>>>> understand. I think they are cool too.
>>>>>> 
>>>>>> Best Jan --
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On 05 May 2015, at 16:52, Johs Ensby <johs@b2w.com>
>>>>>>> wrote:
>>>>>>> 
>>>>>>> Cudos to Giovanni for CouchApp enthusiasm and to
>>>>>>> Ermouth for harsh critisim to Jan and Andy for
>>>>>>> addressing the “story” level
>>>>>>> 
>>>>>>> In spite of its many shortcomings, I still believe
>>>>>>> couchApps could
>>> be
>>>>>> the big recruiter for CouchDB.
>>>>>>> The fact that you can make a design document, direct a
>>>>>>> vhost to its
>>>>>> _rewrite and there create your api for accessing multiple
>>>>>> databases
>>> with
>>>>>> various access levels and multiple design documents is
>>>>>> awesome.
>>>>>>> 
>>>>>>> The main storytelling problem is the overselling as
>>>>>>> Ermouth points
>>> out.
>>>>>>> The overselling starts with the name itself, it should
>>>>>>> not have
>>> “app”
>>>> in
>>>>>> it.
>>>>>>> 
>>>>>>> The concept of a CouchDB app is wrong. The “app” that a
>>>>>>> million young developers are waiting to create
>>> lives
>>>> in
>>>>>> the client.
>>>>>>> They need to learn some CSS and a Javascript framework,
>>>>>>> and CouchDB
>>> is
>>>>>> the only backend they will need until they find out that
>>>>>> they need
>>> more
>>>> in
>>>>>> addition to CouchDB.
>>>>>>> 
>>>>>>> We should quit telling the story about CouchApps and
>>>>>>> start telling
>>> the
>>>>>> story of design docs.
>>>>>>> CouchDB design documents are great. At least as long as
>>>>>>> we keep it simple.
>>>>>>> 
>>>>>>> Our quest should be for powerful simplicity. Simplicity
>>>>>>> always win.
>>>>>>> 
>>>>>>> Johs
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> On 05 May 2015, at 11:49, Jan Lehnardt
>>>>>>>> <jan@apache.org> wrote:
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 05 May 2015, at 11:08, Andy Wenk
>>>>>>>>> <andywenk@apache.org> wrote:
>>>>>>>>> 
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> Jan thanks for raising this important topic!
>>>>>>>>> 
>>>>>>>>> As I had been around and participated when JChris,
>>>>>>>>> Jan and others
>>>>>> started
>>>>>>>>> CouchApps and Benoit took over the work, I am a bit
>>>>>>>>> sad, that
>>>> CouchApps
>>>>>>>>> started to confuse people. And yes it is true, they
>>>>>>>>> are limited
>>> but
>>>>>> have
>>>>>>>>> their place in the history of CouchDB. Far more, it
>>>>>>>>> can easily be
>>>> seen
>>>>>> as
>>>>>>>>> the evolutionary basis for Hoodie and that is a
>>>>>>>>> good thing imho.
>>>>>>>>> 
>>>>>>>>> We should give CouchApps a place to live in the
>>>>>>>>> CouchDB ecosystem
>>>> (not
>>>>>>>>> meant technically). So my proposal is to reactivate
>>>>>>>>> couchapp.org
>>> and
>>>>>> write
>>>>>>>>> one page with info about
>>>>>>>>> 
>>>>>>>>> * what CouchApps are * how one can create one
>>>>>>>>> (links to doku) * what alternatives there are
>>>>>>>>> (kanso, hoodie ...)
>>>>>>>>> 
>>>>>>>>> Furthermore we should include a link on couchdb.org
>>>>>>>>> to
>>> couchapp.org.
>>>>>>>>> 
>>>>>>>>> I think it would be wrong to leave people still in
>>>>>>>>> the dark even
>>>> though
>>>>>>>>> nowadays we think, CouchApps is not the way one
>>>>>>>>> should create a
>>>> WebApp
>>>>>>>>> based on CouchDB (and I don't think the approaches
>>>>>>>>> to create
>>>> CouchApps
>>>>>> was
>>>>>>>>> foolish Jan ;-)). It is our responsibility to
>>>>>>>>> clarify what
>>> CouchApps
>>>>>> are
>>>>>>>>> and why one should move forward to sth. better.
>>>>>>>>> With clarification
>>>>>> comes
>>>>>>>>> clarity
>>>>>>>> 
>>>>>>>> Thanks Andy! — I’m all for the things you mention,
>>>>>>>> once we figure
>>> out
>>>>>> how
>>>>>>>> the CouchApps story fits into the larger CouchDB
>>>>>>>> story without
>>>> confusing
>>>>>>>> anyone.
>>>>>>>> 
>>>>>>>> What’s your take on that? :)
>>>>>>>> 
>>>>>>>> * * *
>>>>>>>> 
>>>>>>>> Also, I think we shouldn’t be afraid to make
>>>>>>>> CouchApp’s place in
>>>>>> CouchDB’s
>>>>>>>> history clear in terms of “This was an idea of its
>>>>>>>> time. Today, we
>>>> think
>>>>>>>> differently. RIP CouchApps”.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Best Jan --
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> All the best
>>>>>>>>> 
>>>>>>>>> Andy
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 5 May 2015 at 10:54, Jan Lehnardt
>>>>>>>>> <jan@apache.org> wrote:
>>>>>>>>> 
>>>>>>>>>> It seems we have a separate discussion going on
>>>>>>>>>> here, so I forked
>>>> the
>>>>>>>>>> thread.
>>>>>>>>>> 
>>>>>>>>>> I’ve seen these two sides ever since we invented
>>>>>>>>>> CouchApps:
>>>>>>>>>> 
>>>>>>>>>> Pro: - CouchApps are amazingly simple - CouchDB
>>>>>>>>>> as an app server is a great idea, I don’t need to
>>>>>>>>>> run
>>> any
>>>>>> other
>>>>>>>>>> infrastructure - this is the future of web
>>>>>>>>>> development - couchapp* is a great tool to manage
>>>>>>>>>> design docs
>>>>>>>>>> 
>>>>>>>>>> (*or erica… etc.)
>>>>>>>>>> 
>>>>>>>>>> Con: - the concept of compiling design docs is
>>>>>>>>>> confusing - even when they get it, they are
>>>>>>>>>> confused that they need a third
>>>>>> party
>>>>>>>>>> tool called `couchapp` to do so, because the
>>>>>>>>>> documentation talks
>>>> about
>>>>>>>>>> building full apps in CouchDB, they have an
>>>>>>>>>> external app and just
>>>>>> want to
>>>>>>>>>> use CouchDB as a database, but couchapp is still
>>>>>>>>>> the tool they
>>> need.
>>>>>>>>>> - the tooling is poor - the tooling is all
>>>>>>>>>> third-party - they can only cover a very limited
>>>>>>>>>> use-case - CouchApps are the only way to use
>>>>>>>>>> CouchDB
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> I see a number of people being passionate about
>>>>>>>>>> CouchApps and I
>>>>>> believe
>>>>>>>>>> their enthusiasm is warranted, CouchApps are a
>>>>>>>>>> neat idea.
>>>>>>>>>> 
>>>>>>>>>> But I also see a greater number of people being
>>>>>>>>>> confused by
>>>> CouchApps
>>>>>> and
>>>>>>>>>> in turn by CouchDB.
>>>>>>>>>> 
>>>>>>>>>> That is not a good situation.
>>>>>>>>>> 
>>>>>>>>>> Let’s think about how (and if) we can fit the
>>>>>>>>>> CouchApp story
>>> into a
>>>>>>>>>> coherent CouchDB story.
>>>>>>>>>> 
>>>>>>>>>> A prerequisite for that is having a coherent
>>>>>>>>>> CouchDB story,
>>> which we
>>>>>> don’t
>>>>>>>>>> have fully finalised yet, but we have talked
>>>>>>>>>> about extensively,
>>> and
>>>>>> the
>>>>>>>>>> consensus is around the “Data where you need it”
>>>>>>>>>> narrative that
>>>>>> emphasises
>>>>>>>>>> replication between CouchDB instances and other
>>>>>>>>>> projects that
>>> speak
>>>>>> the
>>>>>>>>>> replication protocol (especially PouchDB and
>>>>>>>>>> TouchDB).
>>>>>>>>>> 
>>>>>>>>>> How do CouchApps fit into that narrative?
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> * * *
>>>>>>>>>> 
>>>>>>>>>> (Personal view alert: this is just to give some
>>>>>>>>>> more background
>>> on
>>>> my
>>>>>> own
>>>>>>>>>> position, this isn’t meant as a basis for
>>>>>>>>>> discussion)
>>>>>>>>>> 
>>>>>>>>>> I’m personally conflicted. When we set out to
>>>>>>>>>> develop CouchApps,
>>> we
>>>>>>>>>> thought we are inventing a new paradigm for how
>>>>>>>>>> to build the web,
>>>> and
>>>>>>>>>> everybody would follow us, because that would
>>>>>>>>>> enable a true p2p
>>> web.
>>>>>> That
>>>>>>>>>> didn’t happen and probably was a little foolish
>>>>>>>>>> of us :D
>>>>>>>>>> 
>>>>>>>>>> Technically, that would have meant CouchApps had
>>>>>>>>>> to grow a lot
>>> more
>>>>>> and I
>>>>>>>>>> realised quickly that CouchDB is not the right
>>>>>>>>>> place to grow
>>> such a
>>>>>> thing.
>>>>>>>>>> In addition, there are various fully fledged web
>>>>>>>>>> frameworks
>>> already
>>>>>> and
>>>>>>>>>> CouchApps could never really compete in terms of
>>>>>>>>>> person-power and
>>>>>> attention.
>>>>>>>>>> 
>>>>>>>>>> That all led me to re-evaluate the whole value
>>>>>>>>>> proposition, when
>>>>>> things
>>>>>>>>>> like PouchDB came up and the browser became a
>>>>>>>>>> decent application development platform. That
>>>>>>>>>> whole thinking led to the creation of
>>>>>> Hoodie (
>>>>>>>>>> http://hood.ie), which started out with the code
>>>>>>>>>> name CANG
>>> (Couch
>>>>>> Apps
>>>>>>>>>> Next Generation), where we liked some of the core
>>>>>>>>>> ideas of
>>>> CouchApps,
>>>>>> but
>>>>>>>>>> wanted to address the limitations that would
>>>>>>>>>> stifle their
>>> adoption.
>>>>>> Hoodie
>>>>>>>>>> embraces browser-to-server sync to allow fully
>>>>>>>>>> offline apps, it
>>>> allows
>>>>>>>>>> all-javascript-all-json development on the front-
>>>>>>>>>> and back-end.
>>> It
>>>>>> uses the
>>>>>>>>>> database-per-user and the
>>>>>>>>>> _changes-feed-as-async-worker paradigms
>>>> and
>>>>>> it is
>>>>>>>>>> all wrapped into a package that is *really* easy
>>>>>>>>>> to understand
>>> and
>>>> get
>>>>>>>>>> started with. Hoodie, unlike CouchApps, does have
>>>>>>>>>> a fighting
>>> chance
>>>> of
>>>>>>>>>> making CouchDB’s unique features (replication,
>>>>>>>>>> _changes)
>>> available
>>>>>> for a
>>>>>>>>>> larger population and I’m infinitely excited
>>>>>>>>>> about that.
>>>>>>>>>> 
>>>>>>>>>> * * *
>>>>>>>>>> 
>>>>>>>>>> All that doesn’t mean, however, that CouchApps
>>>>>>>>>> don’t have their
>>>>>> place, but
>>>>>>>>>> again, I’m not sure where that place is and the
>>>>>>>>>> place it
>>> currently
>>>> has
>>>>>>>>>> seems to negatively affect CouchDB, so I’d like
>>>>>>>>>> for this list to
>>>>>> think and
>>>>>>>>>> talk about all that for a bit.
>>>>>>>>>> 
>>>>>>>>>> How can we make it that CouchApps strengthen
>>>>>>>>>> CouchDB and not
>>> weaken
>>>>>> it by
>>>>>>>>>> adding confusion?
>>>>>>>>>> 
>>>>>>>>>> How do CouchApps fit into the CouchDB story?
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Best Jan --
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> On 05 May 2015, at 08:45, ermouth
>>>>>>>>>>> <ermouth@gmail.com> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> CouchDB-killing answers
>>>>>>>>>>> 
>>>>>>>>>>> Well... When someone says couchapps is silver
>>>>>>>>>>> bullet – I say
>>> ‘No’
>>>>>> and I
>>>>>>>>>> can
>>>>>>>>>>> prove it. Couchapps have a lot, A LOT of
>>>>>>>>>>> problems, and some of
>>> them
>>>>>> can
>>>>>>>>>> not
>>>>>>>>>>> be solved inside CouchDB. For example, try to
>>>>>>>>>>> implement ACL for
>>>>>>>>>> attachments
>>>>>>>>>>> or try to scale couchapp. You just can‘t do it
>>>>>>>>>>> in reasonable
>>> way.
>>>>>>>>>>> 
>>>>>>>>>>> I know several engineers who tried out
>>>>>>>>>>> couchapps – and left
>>> CouchDB
>>>>>>>>>>> forever. Not because CouchDB itself, but
>>>>>>>>>>> because couchapps.
>>>> O‘Reilly
>>>>>> said
>>>>>>>>>>> it‘s a silver bullet, others said – and what we
>>>>>>>>>>> have? Sloppy and hard-to-debug architecture,
>>>>>>>>>>> that does not scale, has no tooling
>>> and
>>>>>> a lot
>>>>>>>>>>> of security issues.
>>>>>>>>>>> 
>>>>>>>>>>> You gonna solve architecture problems with
>>>>>>>>>>> positive posts?
>>>>>>>>>>> 
>>>>>>>>>>> What I want to say – there is no need to lie
>>>>>>>>>>> and say couchapps
>>> are
>>>>>> great.
>>>>>>>>>>> Because they are not.
>>>>>>>>>>> 
>>>>>>>>>>>> would you like to write down some of your
>>>>>>>>>>>> positive:-))
>>>> experiences?
>>>>>>>>>>> 
>>>>>>>>>>> http://ermouth.livejournal.com/tag/couchdb –
>>>>>>>>>>> sorry, Russian
>>>>>> language.
>>>>>>>>>>> 
>>>>>>>>>>> ermouth
>>>>>>>>>> 
>>>>>>>>>> -- Professional Support for Apache CouchDB: 
>>>>>>>>>> http://www.neighbourhood.ie/couchdb-support/
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> -- Andy Wenk Hamburg - Germany RockIt!
>>>>>>>>> 
>>>>>>>>> GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D
>>>>>>>>> 6BE3 9ED3 9588
>>>>>>>>> 
>>>>>>>>> https://people.apache.org/keys/committer/andywenk.asc
>>>>>>>>
>>>>>>>>
>>>>>>>>> 
- --
>>>>>>>> Professional Support for Apache CouchDB: 
>>>>>>>> http://www.neighbourhood.ie/couchdb-support/<
>>>>>> http://www.neighbourhood.ie/couchdb-support/>
>>>>>> 
>>>>>> -- Professional Support for Apache CouchDB: 
>>>>>> http://www.neighbourhood.ie/couchdb-support/
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> -- Andy Wenk Hamburg - Germany RockIt!
>>>>> 
>>>>> GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3
>>>>> 9ED3 9588
>>>>> 
>>>>> https://people.apache.org/keys/committer/andywenk.asc
>>>> 
>>>> -- Professional Support for Apache CouchDB: 
>>>> http://www.neighbourhood.ie/couchdb-support/
>>>> 
>>>> 
>>> 
>>> 
>>> -- Andy Wenk Hamburg - Germany RockIt!
>>> 
>>> GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3
>>> 9588
>>> 
>>> https://people.apache.org/keys/committer/andywenk.asc
>> 
>> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVSmQmAAoJED+W7gN+c0gcDHQH/jPnnBySZTJovwoYZndZIEg4
ZvrLx31heHNqNetroX/JUQWrgjx2xBkes3IKAFB2zBULELRvHMmF1G8Kpmafz0Ki
hiOQ/spa9P1hBeR7PaykqJ9U5XMLASyfDK3adHdL7jpowtX2gf1ug6JmFc94qnU8
03UmpNKhRy7geeyIaW7Vcb7LADUHO/+8GGmNLiyVixOfJ+AwdKQA30cSXulCQf5q
pgzABlkRntM4iqct6Czp5dBbc2erAJFfFgu8NmaWL+JnaLYsgIwq6SnHSdMp2BvN
kXsWQA4kl5LvKY1riEV3sO23onbbB1mqgb0amxlaH9apk1GjhqvbBPoQ51hYv/o=
=QRof
-----END PGP SIGNATURE-----