couchdb-marketing mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giovanni Lenzi <g.le...@smileupps.com>
Subject Re: Re: the future of couchapp
Date Thu, 07 May 2015 16:31:49 GMT
just fyi... all started from this discussion, where I was trying to propose
a list of ideas to push couchdb marketing:

http://couchdb.markmail.org/search/?q=#query:%20list%3Aorg.apache.couchdb.marketing+page:8+mid:zaty7v63giukyykh+state:results


2015-05-07 18:09 GMT+02:00 Miles Fidelman <mfidelman@meetinghouse.net>:

> originally posted to user@ - reposted here at Jan's request (slightly
> trimmed)
>
> -------- Forwarded Message --------
>
> Speaking as someone who writes proposals for a living, what I find
> confusing are terms that sound very clear - such as "retire CouchApps" -
> that require digging through lots of distributed materials to find
> clarification of what you really mean.
>
> I.e., it's not "CouchApps" that are confusing - it's the verbiage that's
> confusing.
>
> Personally, I'd like to see more language like:
>
> CouchDB includes application server functionality, that supports both
> client-side and server side native applications, which we call CouchApps."
> or maybe,
> CouchApps are CouchDB's equivalent of Java applets and servelets.
>
> I think those are pretty clear descriptions of CouchApps, at a
> conceptual level.  (If not, then maybe CouchApps really are confusing.)
>
> Miles Fidelman
>
>
>
> Jan Lehnardt wrote:
>
>> Funny how this proves my point about CouchApps being confusing. We can't
>> even talk about their future without talking past each other.
>>
>> In addition, cherry-picking quotes from my emails won't help to clarify
>> things. I understand you *can* read a position of "let's remove 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
>>>>>>>>>>>>>
>>>>>>>>>>>>>


-- 
Giovanni Lenzi
www.smileupps.com
Smileupps Couchapps Store

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message