couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Miles Fidelman <mfidel...@meetinghouse.net>
Subject Re: the future of couchapp
Date Thu, 07 May 2015 15:05:50 GMT
Speaking as someone who writes proposals for a living, what I find 
confusing are terms that sound very clear - such as "retire CouchApps" - 
that require digging through lots of distributed materials to find 
clarification of what you really mean.

I.e., it's not "CouchApps" that are confusing - it's the verbiage that's 
confusing.

Personally, I'd like to see more language like:

CouchDB includes application server functionality, that supports both 
client-side and server side native applications, which we call CouchApps."
or maybe,
CouchApps are CouchDB's equivalent of Java applets and servelets.

I think those are pretty clear descriptions of CouchApps, at a 
conceptual level.  (If not, then maybe CouchApps really are confusing.)

Miles Fidelman



Jan Lehnardt wrote:
> Funny how this proves my point about CouchApps being confusing. We can't even talk about their future without talking past each other.
>
> In addition, cherry-picking quotes from my emails won't help to clarify things. I understand you *can* read a position of "let's remove CouchApps" into what I wrote, by only if you selectively ignore some of the things I also said. I don't think that is useful.
>
> Please join marketing@ to join the uncut discussion there.
>
> Best
> Jan
> --
>
> Best
> Jan
> --
>> On 07.05.2015, at 15:10, Harald Kisch <haraldkisch@gmail.com> wrote:
>>
>> Sorry Jan, please don't take it personally but in your both emails you
>> definitely claimed out, that couchapps does'nt fit in YOUR CouchDB-Story.
>>
>> In
>>
>> http://markmail.org/message/no3jfksdxjcgxz4d
>>
>> you personally said:
>> "Technically, that would have meant CouchApps had to grow a lot more and I
>> realised quickly that CouchDB is not the right place to grow such a thing."
>>
>> Sorry but for me it means you don't want CouchDB to have an App-Engine
>> inside. The only confusion is: What could be the issue for that? Every
>> database vendor works for decades on it? And why peer-to-peer should be
>> bad? Think on Git, torrent network, etc. pp. are these projects not the
>> leading inventions of the last decades based on peer-to-peer? And yes,
>> CouchDB is NOW extremely powerful with Apps executed out of its database
>> core and replicated anywhere without the need of permanent internet
>> connection!
>>
>> Also in
>>
>> http://markmail.org/message/xla3hulea4lo5duw
>>
>> you personally said:
>> "figure out a plan to retire “CouchApp”"
>>
>> Sorry this words are not misunderstandable for me. And I am wondering why
>> and how you can say that. And if you really want to "retire CouchApp"
>> because of confusions (for me it is the other way around - the storage is
>> part of the App-Engine because stupid containers you can find everywhere
>> based on node.js etc. to support the same as CouchDB's native App
>> Core-Feature called Couchapp)
>>
>> CouchApps for me "are" the CouchDB Story. There is no confusion about that.
>> Please do not claim that somone has something against you and please take
>> it objective not emotional. But if you take such desruptive things into the
>> community, you should also stand for it to explain them accordingly and not
>> start to change the basics to loose all the current users of that
>> game-changing core-feature.
>>
>> Best
>> Harald
>>
>>> On Thu, May 7, 2015 at 1:14 PM, Jan Lehnardt <jan@apache.org> 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 <haraldkisch@gmail.com> wrote:
>>>>
>>>> Sorry guys, my eyes dont believe what they see..
>>>> @Jan: How are you? long time not spoken to eachother. How is Lena? What
>>> she
>>>> is thinking about couchapps?
>>>>
>>>> Why not to make a list of pros and cons for couchapps?
>>>> Did you ask jchris about removing couchapps?
>>>> Or why you don't directly ask Damien aboout the cause he implements it?
>>>>
>>>> What is your benefit removing it?
>>>>
>>>> For my part I have been successfully using it since 2008 and this is my
>>>> favorite use case for building secure, anywhere applications for the
>>>> industry and I would apreciate improvements on couchapps regarding
>>>> Authentication, LDAP and Active Directory erlang modules like built in
>>> 2010
>>>> and never improved.
>>>>
>>>> We should not forget what CouchDB is all about. And for me the guys who
>>>> claim out to remove couchapp simply forget the power Damien have built in
>>>> and the power who made CouchDB proud to kick-off the no-sql area.
>>>> Dont forget who Damien really is. He is one of the leading developers of
>>>> Domino Notes aka Lotus Notes aka IBM Notes, registering 3 patents in USA
>>>> for it. Because only older guys know it, Lotus Notes was the previously
>>>> business standard groupware software for large scale companies before SAP
>>>> was destroying it's reputations with the help of IBM (which wanted only
>>> to
>>>> sell their DB2 Database). Everybody who was working with Lotus Notes
>>> begun
>>>> to love it. Not so SAP-Users, they are hating their daily work with SAP
>>>> because it simply don't work (complexity).
>>>>
>>>> Couchapp is not complex and still have the power lotus notes has.
>>> Remember:
>>>> Damien has built CouchDB because "everybody was talking about it, and
>>>> nobody did it", until Damien got it done with CouchDB.
>>>>
>>>> In my opinion, and there are much more people who think in this way,
>>>> Couchapp is the most important and game-changing feature in CouchDB. But
>>>> also most misunderstood and most criticised, partly because of the fear
>>> it
>>>> creates amoung other database vendors who always want exactly this:
>>>> Application execution directly out of the database core. Yes, exactly
>>> this
>>>> is Couchapp! And it does it without CLR (Microsoft SQLSERVER) or JAVA
>>>> (Oracle Forms) and its terribly complex architecture.
>>>>
>>>> Please stop using CouchDB as stupid data container and think more about
>>> it
>>>> as Web-Application-Engine!
>>>>
>>>> Cheers
>>>> Harald Kisch
>>>>
>>>> ---
>>>>
>>>> Given the importance of this topic: the future of couchapp... I'm moving
>>>> this to the user@ mailing list.
>>>>
>>>> This should be definitely something @users should be involved in.. at
>>> least
>>>> those interested in Couchapps.
>>>>
>>>> To recap:
>>>> Jan: wants to remove Couchapp name and design doc functions because it
>>>> finds them to be source of confusion
>>>>
>>>> ermouth: pointed out Couchapps are not silver bullet but they cover many
>>>> use cases and there are rooms for improvements
>>>>
>>>> giovanni: pointed out many users and industries today are using couchapps
>>>> successfully, withouth such this confusion between what couchdb is and
>>> what
>>>> couchapps are, and they won't simply understand couchapps removal,
>>> leading
>>>> couchdb to a second-death. Moreover couchapps potential has increased a
>>> lot
>>>> within the last months: now they are secure and has support for features
>>>> like e-mail, sms, paypal/stripe integration, events scheduling.
>>>>
>>>> johs: pointed out couchapps are big recruiter for couchdb and they should
>>>> not be dropped: a fadeout of "couchapp" name withouth any removal should
>>> be
>>>> sufficient
>>>>
>>>> andy: was not aware of the name confusion, and wanted to keep the name
>>>>
>>>> What you all think about it?
>>>>
>>>>
>>>> 2015-05-05 22:35 GMT+02:00 Giovanni Lenzi <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


-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra


Mime
View raw message