You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Dragos Stoica <dr...@yahoo.com.INVALID> on 2015/05/15 13:27:39 UTC
Răspuns: the future of couchapp
I want to state clearly my possition: I am a big fan of couchapp!
We started with serious use of CouchDB in 2012 and we produced 3 tools until now that are couchapps and/or use couchapp mechanism.1. https://github.com/iqcouch/couchapp-wrapper a tool that uses couchapp to sync design docs from a CouchDB with a local repository. Does not deal with attachments.2. https://github.com/iqcouch/designeditor a couchapp that is used as programming tool and design doc management. This tool was our companion since 20123. https://github.com/iqcouch/designeditor/tree/appzip a new approach, it is a couchapp aimed to facilitate couchapp deployment as a zip archive. There are 2 more couchapps: https://github.com/iqcouch/sr_manager (this includes PouchDB also on mobile client side) and https://github.com/iqcouch/plan4 (WIP) that are active.
Design editor, SR Manager and Plan4 were structured as a appzip deployment structures.
So, what is my point?!Definitely couchapp is a great tool, a huge contribution to CouchDB user adoption and a step forward in application development. I imply that couchapp should stay in the ecosystem. In this form or as a CouchDB companion (exposed as external service or plug-in).On the other hand, we played with the idea of deploying couchapps as zip archives and we got good results. Maybe we will propose a CouchDB plugin for the community, appzip will remain free.
All the best, Dragos STOICA
În Joi, 7 Mai 2015 18:55:20, Jan Lehnardt <ja...@apache.org> a scris:
> On 07.05.2015, at 17:05, Miles Fidelman <mf...@meetinghouse.net> wrote:
>
> 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 didn't bring this to user@ for that exact reason. Let's continue this discussion on marketing@.
Can you repost your thoughts there?
Best
Jan
--
>
> 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 <ha...@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 <ja...@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 <ha...@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....@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" <an...@apache.org> ha
>>>> scritto:
>>>>>>>> On 5 May 2015 at 18:44, Jan Lehnardt <ja...@apache.org> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 05 May 2015, at 18:37, Andy Wenk <an...@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 <ja...@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 <jo...@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 <ja...@apache.org>
>>>>> wrote:
>>>>>>>>>>>>> On 05 May 2015, at 11:08, Andy Wenk <an...@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 <ja...@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 <er...@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
>