Fwd: Re: the future of couchapp

[Miles Fidelman <mf...@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 <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

Re: the future of couchapp

[Miles Fidelman <mf...@meetinghouse.net>]

Or, instead of coining a new term, and having to explain it, just say it 
in words:
CouchDB = a database server + a web server + an app server, rolled into one
Though I'm not sure that really captures the essence.

Giovanni Lenzi wrote:
> Back on track..
>
> the story for couchdb may be to start refering couchdb with a new term
> like: "web-app-db server", or engine if you prefer.. where its primary
> meaning is not "web application" and "db server" but instead: "web server",
> "app server" and "db server".. As Paul alread said, to me too this is the
> power of couchdb.
>
> So the new term "web-app-db" may sound weird at first, but I think it's
> only a matter of telling the users what it is.
>
>
> 2015-05-07 18:31 GMT+02:00 Giovanni Lenzi <g....@smileupps.com>:
>
>> 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 <mf...@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 <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
>>>>>>>>>>>>>>>
>>
>> --
>> Giovanni Lenzi
>> www.smileupps.com
>> Smileupps Couchapps Store
>>
>
>


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

Re: the future of couchapp

[Giovanni Lenzi <g....@smileupps.com>]

I would like to attach you some public analytics(Keyword planner of google
adwords) referring to google search queries volume for term "couchdb"
within the last 2 years.

Maybe this can be a good starting point to understand where the current
couchdb market Joan was referring to, has led couchdb so far.

2015-05-11 9:18 GMT+02:00 Giovanni Lenzi <g....@smileupps.com>:

> Hi Joan, thanks for your useful reminders. I think you hit the main point.
>
> 2015-05-09 20:26 GMT+02:00 Joan Touzet <wo...@apache.org>:
>
>> *** TL;DR: the people who are willing to spend anywhere from
>> thousands to millions of dollars on a CouchDB-based solution aren't
>> interested in CouchApps. I think the discussion to date is missing
>> this, and as such, is entirely unrepresentative of the current
>> market for Apache CouchDB.
>>
>
>
>
>> The answer is that there are practically no customers of Cloudant/IBM
>> who are banking on CouchApps for any serious need. Every client that
>> I can think of - meaning they have a dedicated cluster, and aren't
>> using the shared cluster service ....
>>
> Cloudant built out a document-level (and field-level!) security
>> solution for one customer, about two years ago now. While there was
>> initial interest, performance considerations lead to the solution
>> being backburnered for further consideration. Even in that situation,
>> CouchApps weren't the primary concern -- database-level enforcement
>> of security rules *was*.
>>
>
> From what you cc'ed and then say, it seems that CouchDB market should be
> strictly the same as Cloudant market.. Is it this what Mike and you would
> like to say? And if yes, why?
>
> Why an Apache project, should strictly target companies with thousand to
> millions dollars?
> Is this allowed by "the apache way"?
> Are there other Apache examples of company-driven project?
>
> Sorry for all these questions but I am very very ignorant in this. I
> thought a project should only be driven from its users as its most
> important participants.
>
> Thanks in advance for your useful answers.
>
>
>
>>
>> Within Cloudant, perhaps Simon Metson was the primary proponent of
>> using CouchApps for serious purposes. He used them in the "For
>> Developers" section of the website to help demonstrate various key
>> features of the platform, including the new MongoDB-inspired Mango
>> feature that's now a part of CouchDB 2.0. Diana Thayer (@garbados)
>> picked up on this and built a documentation framework on top of
>> CouchApps. This, to me, is perhaps the ideal use of CouchApps:
>> unsecured content, read-only, displayed in different formats based
>> upon what the end user needs, and self-hosted by CouchDB (so you
>> can view the product's documentation using the product itself).
>> More information on this use is at:
>>
>>
>> https://mail-archives.apache.org/mod_mbox/couchdb-dev/201410.mbox/%3C28603443.66.1414446738764.JavaMail.joant@Joans-MacBook-Pro.local%3E
>>
>>
>>
>>
>>
>> ----- Original Message -----
>> > From: "Miles Fidelman" <mf...@meetinghouse.net>
>> > To: marketing@couchdb.apache.org
>> > Sent: Friday, May 8, 2015 11:21:28 AM
>> > Subject: Re: the future of couchapp
>> >
>> > Let's be clear.
>> > (Good) marketing isn't about selling a solution to folks who don't
>> > have
>> > a problem in the first place, it's about it's identifying problems
>> > for
>> > which we offer a solution.
>> >
>> > And.. it occurs to me that Cloudant has been doing market research
>> > and
>> > "real" marketing - perhaps some folks from Cloudant might share some
>> > findings related to CouchDB (as opposed to those that might relate to
>> > their commercial extensions and services)?
>> >
>> > Miles Fidelman
>> >
>> >
>> >
>> > Giovanni Lenzi wrote:
>> > >> translates user@ decisions in "how to drive them to the public"?
>> > > or maybe better how to drive dev@ implemented features to the
>> > > public ?
>> > >
>> > > 2015-05-08 16:57 GMT+02:00 Giovanni Lenzi <g....@smileupps.com>:
>> > >
>> > >> Got it, Joan. Thanks for the useful reminder, considered I am a
>> > >> total
>> > >> newbie here, I definitely don't know how decision-making process
>> > >> is driven.
>> > >>
>> > >> We will cut the "features" part from this discussion then and take
>> > >> it to
>> > >> the devs@ list
>> > >>
>> > >> Here we should then focus on @jan's request about the story for
>> > >> couchapps.. given that until 2 days ago that was somehow uncertain
>> > >>
>> > >> But I think too this is more a user@ topic... isn't maybe
>> > >> marketing more
>> > >> appropriate to translates user@ decisions in "how to drive them to
>> > >> the
>> > >> public"? If you all agree with that, you can move this discussion
>> > >> to user@
>> > >> or dev@, don't know what is preferable.
>> > >>
>> > >>
>> > >> 2015-05-08 15:56 GMT+02:00 Joan Touzet <wo...@apache.org>:
>> > >>
>> > >>> Hi all,
>> > >>>
>> > >>> PMC hat on...
>> > >>>
>> > >>> Reminding you *again* that we should not be using the MARKETING
>> > >>> list to
>> > >>> discuss new FEATURES and functionality for Apache CouchDB. We are
>> > >>> not
>> > >>> like a company where marketing makes up what they want to do, and
>> > >>> development is forced to implement it. While it's a good idea to
>> > >>> have a
>> > >>> feedback loop between marketing and development, I am especially
>> > >>> keen to
>> > >>> not see Apache CouchDB turn into a marketing-driven development
>> > >>> effort.
>> > >>>
>> > >>> If you are proposing new CouchDB features, please make those
>> > >>> proposals
>> > >>> on the dev@ mailing list. And if you are willing to *develop* and
>> > >>> *support* those functions - even better. Current CouchDB
>> > >>> development
>> > >>> bandwidth is extremely limited, and would best be served by
>> > >>> helping you
>> > >>> to understand the current design's constraints, and the
>> > >>> difficulties
>> > >>> that may be inherent in what you ask for.
>> > >>>
>> > >>> Best regards,
>> > >>> Joan
>> > >>>
>> > >>> ----- Original Message -----
>> > >>>> From: "Giovanni Lenzi" <g....@smileupps.com>
>> > >>>> To: marketing@couchdb.apache.org
>> > >>>> Sent: Friday, May 8, 2015 4:05:12 AM
>> > >>>> Subject: Re: the future of couchapp
>> > >>>>
>> > >>>>> A service-trigger feature could be one of the new features of
>> > >>>>> Couch
>> > >>>>> apps.
>> > >>>> if possible, would be awesome :)
>> > >>>>
>> > >>>>> some clear design goals and a very limited set of features to
>> > >>>>> add
>> > >>>>> to
>> > >>>> CouchDB ddocs and focus on an in-browser tool (add features to
>> > >>>> Fauxton)
>> > >>>> that removes the need for new developers to learn git and build
>> > >>>> tools
>> > >>
>> > >>
>> > >> --
>> > >> Giovanni Lenzi
>> > >> www.smileupps.com
>> > >> Smileupps Cloud App Store
>> > >>
>> > >
>> > >
>> >
>> >
>> > --
>> > In theory, there is no difference between theory and practice.
>> > In practice, there is.   .... Yogi Berra
>> >
>> >
>>
>
>
>
> --
> Giovanni Lenzi
> www.smileupps.com
> Smileupps Cloud App Store
>



-- 
Giovanni Lenzi
www.smileupps.com
Smileupps Cloud App Store

Re: the future of couchapp

[Garren Smith <ga...@apache.org>]

Alexander thank you. That is 100% correct nicely said.


> On 11 May 2015, at 3:01 PM, Alexander Shorin <kx...@gmail.com> wrote:
> 
> Sorry, for intruding into your conversation, but let me throw you a
> thought I have.
> 
> Apache CouchDB, as it was said, is a volunteer project, where each
> committer takes care about what they personally likes or need for own
> business: Cloudnant contributors cares about cluster feature and
> stable core, Jan cares about simplicity of usage CouchDB with no
> confusing things, Robert Kowalski like to work mostly on frontend part
> of the project - sorry if I didn't explain precisely position and
> motivation of the each, but it doesn't matter. What I want to say, is
> everybody works on what they likes/need/feels important.
> 
> Obliviously, couchapp feature lacks of love, care and attention for
> quite long of time and there is no explicit leader to work on this
> feature and evangelist to promote. If couchapps feature is critical
> for Smileyupps business and they have ideas how to improve it and
> resources to maintain it, why not to take Cloudant as an example and
> become a contributor? I think, with such plan, everybody will win:
> CouchDB will get more powerful couchapps, Smileyupps will be able to
> be more attractive for their clientèle. And by the way, you eventually
> may help to solve confusion around couchapps.
> 
> Sounds like business-driven development, but I'd like to think about
> it as about inventions into open source for better business. After
> all, business successful features mostly may receive warm welcome by a
> community, while business specific will get cut off in order to have
> more general solution that fits most in the end.
> 
> Otherwise I see whole this discussion as arguing of two people where
> first continues keeps saying "we need couchapps! couchapps are cool!"
> and the second one responses "couchapps are full of flaws and
> confusion!". Without the one who will enter and say "Hey! Calm down,
> I'll sort all the problems" there wouldn't be any good solution and
> couchapps will die as technology by timeout: era of HTTP/2 is coming
> which going to change a lot of things, while I don't mention existed
> websockets.
> 
> So what do you think about?
> 
> --
> ,,,^..^,,,
> 
> 
> On Mon, May 11, 2015 at 10:18 AM, Giovanni Lenzi <g....@smileupps.com> wrote:
>> Hi Joan, thanks for your useful reminders. I think you hit the main point.
>> 
>> 2015-05-09 20:26 GMT+02:00 Joan Touzet <wo...@apache.org>:
>> 
>>> *** TL;DR: the people who are willing to spend anywhere from
>>> thousands to millions of dollars on a CouchDB-based solution aren't
>>> interested in CouchApps. I think the discussion to date is missing
>>> this, and as such, is entirely unrepresentative of the current
>>> market for Apache CouchDB.
>>> 
>> 
>> 
>> 
>>> The answer is that there are practically no customers of Cloudant/IBM
>>> who are banking on CouchApps for any serious need. Every client that
>>> I can think of - meaning they have a dedicated cluster, and aren't
>>> using the shared cluster service ....
>>> 
>> Cloudant built out a document-level (and field-level!) security
>>> solution for one customer, about two years ago now. While there was
>>> initial interest, performance considerations lead to the solution
>>> being backburnered for further consideration. Even in that situation,
>>> CouchApps weren't the primary concern -- database-level enforcement
>>> of security rules *was*.
>>> 
>> 
>> From what you cc'ed and then say, it seems that CouchDB market should be
>> strictly the same as Cloudant market.. Is it this what Mike and you would
>> like to say? And if yes, why?
>> 
>> Why an Apache project, should strictly target companies with thousand to
>> millions dollars?
>> Is this allowed by "the apache way"?
>> Are there other Apache examples of company-driven project?
>> 
>> Sorry for all these questions but I am very very ignorant in this. I
>> thought a project should only be driven from its users as its most
>> important participants.
>> 
>> Thanks in advance for your useful answers.
>> 
>> 
>> 
>>> 
>>> Within Cloudant, perhaps Simon Metson was the primary proponent of
>>> using CouchApps for serious purposes. He used them in the "For
>>> Developers" section of the website to help demonstrate various key
>>> features of the platform, including the new MongoDB-inspired Mango
>>> feature that's now a part of CouchDB 2.0. Diana Thayer (@garbados)
>>> picked up on this and built a documentation framework on top of
>>> CouchApps. This, to me, is perhaps the ideal use of CouchApps:
>>> unsecured content, read-only, displayed in different formats based
>>> upon what the end user needs, and self-hosted by CouchDB (so you
>>> can view the product's documentation using the product itself).
>>> More information on this use is at:
>>> 
>>> 
>>> https://mail-archives.apache.org/mod_mbox/couchdb-dev/201410.mbox/%3C28603443.66.1414446738764.JavaMail.joant@Joans-MacBook-Pro.local%3E
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ----- Original Message -----
>>>> From: "Miles Fidelman" <mf...@meetinghouse.net>
>>>> To: marketing@couchdb.apache.org
>>>> Sent: Friday, May 8, 2015 11:21:28 AM
>>>> Subject: Re: the future of couchapp
>>>> 
>>>> Let's be clear.
>>>> (Good) marketing isn't about selling a solution to folks who don't
>>>> have
>>>> a problem in the first place, it's about it's identifying problems
>>>> for
>>>> which we offer a solution.
>>>> 
>>>> And.. it occurs to me that Cloudant has been doing market research
>>>> and
>>>> "real" marketing - perhaps some folks from Cloudant might share some
>>>> findings related to CouchDB (as opposed to those that might relate to
>>>> their commercial extensions and services)?
>>>> 
>>>> Miles Fidelman
>>>> 
>>>> 
>>>> 
>>>> Giovanni Lenzi wrote:
>>>>>> translates user@ decisions in "how to drive them to the public"?
>>>>> or maybe better how to drive dev@ implemented features to the
>>>>> public ?
>>>>> 
>>>>> 2015-05-08 16:57 GMT+02:00 Giovanni Lenzi <g....@smileupps.com>:
>>>>> 
>>>>>> Got it, Joan. Thanks for the useful reminder, considered I am a
>>>>>> total
>>>>>> newbie here, I definitely don't know how decision-making process
>>>>>> is driven.
>>>>>> 
>>>>>> We will cut the "features" part from this discussion then and take
>>>>>> it to
>>>>>> the devs@ list
>>>>>> 
>>>>>> Here we should then focus on @jan's request about the story for
>>>>>> couchapps.. given that until 2 days ago that was somehow uncertain
>>>>>> 
>>>>>> But I think too this is more a user@ topic... isn't maybe
>>>>>> marketing more
>>>>>> appropriate to translates user@ decisions in "how to drive them to
>>>>>> the
>>>>>> public"? If you all agree with that, you can move this discussion
>>>>>> to user@
>>>>>> or dev@, don't know what is preferable.
>>>>>> 
>>>>>> 
>>>>>> 2015-05-08 15:56 GMT+02:00 Joan Touzet <wo...@apache.org>:
>>>>>> 
>>>>>>> Hi all,
>>>>>>> 
>>>>>>> PMC hat on...
>>>>>>> 
>>>>>>> Reminding you *again* that we should not be using the MARKETING
>>>>>>> list to
>>>>>>> discuss new FEATURES and functionality for Apache CouchDB. We are
>>>>>>> not
>>>>>>> like a company where marketing makes up what they want to do, and
>>>>>>> development is forced to implement it. While it's a good idea to
>>>>>>> have a
>>>>>>> feedback loop between marketing and development, I am especially
>>>>>>> keen to
>>>>>>> not see Apache CouchDB turn into a marketing-driven development
>>>>>>> effort.
>>>>>>> 
>>>>>>> If you are proposing new CouchDB features, please make those
>>>>>>> proposals
>>>>>>> on the dev@ mailing list. And if you are willing to *develop* and
>>>>>>> *support* those functions - even better. Current CouchDB
>>>>>>> development
>>>>>>> bandwidth is extremely limited, and would best be served by
>>>>>>> helping you
>>>>>>> to understand the current design's constraints, and the
>>>>>>> difficulties
>>>>>>> that may be inherent in what you ask for.
>>>>>>> 
>>>>>>> Best regards,
>>>>>>> Joan
>>>>>>> 
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Giovanni Lenzi" <g....@smileupps.com>
>>>>>>>> To: marketing@couchdb.apache.org
>>>>>>>> Sent: Friday, May 8, 2015 4:05:12 AM
>>>>>>>> Subject: Re: the future of couchapp
>>>>>>>> 
>>>>>>>>> A service-trigger feature could be one of the new features of
>>>>>>>>> Couch
>>>>>>>>> apps.
>>>>>>>> if possible, would be awesome :)
>>>>>>>> 
>>>>>>>>> some clear design goals and a very limited set of features to
>>>>>>>>> add
>>>>>>>>> to
>>>>>>>> CouchDB ddocs and focus on an in-browser tool (add features to
>>>>>>>> Fauxton)
>>>>>>>> that removes the need for new developers to learn git and build
>>>>>>>> tools
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Giovanni Lenzi
>>>>>> www.smileupps.com
>>>>>> Smileupps Cloud App Store
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> In theory, there is no difference between theory and practice.
>>>> In practice, there is.   .... Yogi Berra
>>>> 
>>>> 
>>> 
>> 
>> 
>> 
>> --
>> Giovanni Lenzi
>> www.smileupps.com
>> Smileupps Cloud App Store

Re: the future of couchapp

[Alexander Shorin <kx...@gmail.com>]

Ouch, sorry, wrong buttons.

Giovanni, no need to be sorry. I think that was great that we clean
the dust from the old problems and took a look on them with the fresh
sight. It's good that this discussion happened.

There is no need to be professional Erlang programmer to handle this
feature: just be the one with burning heart and good will - experience
it a matter of time and we can help to get it as much as we can. Hope
one day your team will join us to make CouchDB better.

But informational support, as what it was in your original post, is
also very important as much as the code, may be even more, and we
always appreciate such kind of work. Hope you didn't loose interest to
push it forward after all what was said on this list (:

--
,,,^..^,,,


On Tue, May 12, 2015 at 5:00 PM, Alexander Shorin <kx...@gmail.com> wrote:
> --
> ,,,^..^,,,
>
>
> On Tue, May 12, 2015 at 4:48 PM, Giovanni Lenzi <g....@smileupps.com> wrote:
>> Thanks Alexander for you thougths. They have been very useful for us to
>> have a feeling of the current developer team status and preferences. We
>> were simply not aware of such this situation.
>>
>> Unfortunately currently we don't have resources and erlang competences to
>> join couchdb team. We have full respect for Cloudant and developers working
>> in Cloudant and I understand everyone wants to work on what he cares most,
>> even regardless of marketing considerations to increase interest in the
>> project and ultimately the committers adoption rate.
>>
>> My starting intention with the thread 'couchdb articles, pills, tutorials'
>> wasn't absolutely to bore anyone with such this kind of discussion. I'm
>> very sorry for that, but in the end, I think it has been also useful to
>> define both couchdb and smileupps' plans for the future.
>>
>> I'm very happy jan likes tim black's proposal to market both "couchdb" and
>> "couchapps" separately and clearly, to allow them both to grow. We found it
>> very very good to prevent confusion and from a marketing perspective too.
>>
>> Having said this, even if currently we can't do more than what we are
>> already doing to grab users' interest, I'm still looking forward to work
>> together with you in the future, in a way or another.
>>
>> Thanks all for your patience and this useful discussion,
>>
>> Best Regards,
>>
>> Smileupps Team
>>
>>
>> Il giorno 11/mag/2015 18:47, "Jan Lehnardt" <ja...@apache.org> ha scritto:
>>
>>>
>>> > On 11 May 2015, at 15:01, Alexander Shorin <kx...@gmail.com> wrote:
>>> >
>>> > Sorry, for intruding into your conversation, but let me throw you a
>>> > thought I have.
>>> >
>>> > Apache CouchDB, as it was said, is a volunteer project, where each
>>> > committer takes care about what they personally likes or need for own
>>> > business: Cloudnant contributors cares about cluster feature and
>>> > stable core, Jan cares about simplicity of usage CouchDB with no
>>> > confusing things, Robert Kowalski like to work mostly on frontend part
>>> > of the project - sorry if I didn't explain precisely position and
>>> > motivation of the each, but it doesn't matter. What I want to say, is
>>> > everybody works on what they likes/need/feels important.
>>> >
>>> > Obliviously, couchapp feature lacks of love, care and attention for
>>> > quite long of time and there is no explicit leader to work on this
>>> > feature and evangelist to promote. If couchapps feature is critical
>>> > for Smileyupps business and they have ideas how to improve it and
>>> > resources to maintain it, why not to take Cloudant as an example and
>>> > become a contributor? I think, with such plan, everybody will win:
>>> > CouchDB will get more powerful couchapps, Smileyupps will be able to
>>> > be more attractive for their clientèle. And by the way, you eventually
>>> > may help to solve confusion around couchapps.
>>> >
>>> > Sounds like business-driven development, but I'd like to think about
>>> > it as about inventions into open source for better business. After
>>> > all, business successful features mostly may receive warm welcome by a
>>> > community, while business specific will get cut off in order to have
>>> > more general solution that fits most in the end.
>>> >
>>> > Otherwise I see whole this discussion as arguing of two people where
>>> > first continues keeps saying "we need couchapps! couchapps are cool!"
>>> > and the second one responses "couchapps are full of flaws and
>>> > confusion!". Without the one who will enter and say "Hey! Calm down,
>>> > I'll sort all the problems" there wouldn't be any good solution and
>>> > couchapps will die as technology by timeout: era of HTTP/2 is coming
>>> > which going to change a lot of things, while I don't mention existed
>>> > websockets.
>>> >
>>> > So what do you think about?
>>>
>>> I think I agree 100% with what you are saying, thanks Alexander :)
>>>
>>> Best
>>> Jan
>>> --
>>>
>>> >
>>> > --
>>> > ,,,^..^,,,
>>> >
>>> >
>>> > On Mon, May 11, 2015 at 10:18 AM, Giovanni Lenzi <g....@smileupps.com>
>>> wrote:
>>> >> Hi Joan, thanks for your useful reminders. I think you hit the main
>>> point.
>>> >>
>>> >> 2015-05-09 20:26 GMT+02:00 Joan Touzet <wo...@apache.org>:
>>> >>
>>> >>> *** TL;DR: the people who are willing to spend anywhere from
>>> >>> thousands to millions of dollars on a CouchDB-based solution aren't
>>> >>> interested in CouchApps. I think the discussion to date is missing
>>> >>> this, and as such, is entirely unrepresentative of the current
>>> >>> market for Apache CouchDB.
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >>> The answer is that there are practically no customers of Cloudant/IBM
>>> >>> who are banking on CouchApps for any serious need. Every client that
>>> >>> I can think of - meaning they have a dedicated cluster, and aren't
>>> >>> using the shared cluster service ....
>>> >>>
>>> >> Cloudant built out a document-level (and field-level!) security
>>> >>> solution for one customer, about two years ago now. While there was
>>> >>> initial interest, performance considerations lead to the solution
>>> >>> being backburnered for further consideration. Even in that situation,
>>> >>> CouchApps weren't the primary concern -- database-level enforcement
>>> >>> of security rules *was*.
>>> >>>
>>> >>
>>> >> From what you cc'ed and then say, it seems that CouchDB market should be
>>> >> strictly the same as Cloudant market.. Is it this what Mike and you
>>> would
>>> >> like to say? And if yes, why?
>>> >>
>>> >> Why an Apache project, should strictly target companies with thousand to
>>> >> millions dollars?
>>> >> Is this allowed by "the apache way"?
>>> >> Are there other Apache examples of company-driven project?
>>> >>
>>> >> Sorry for all these questions but I am very very ignorant in this. I
>>> >> thought a project should only be driven from its users as its most
>>> >> important participants.
>>> >>
>>> >> Thanks in advance for your useful answers.
>>> >>
>>> >>
>>> >>
>>> >>>
>>> >>> Within Cloudant, perhaps Simon Metson was the primary proponent of
>>> >>> using CouchApps for serious purposes. He used them in the "For
>>> >>> Developers" section of the website to help demonstrate various key
>>> >>> features of the platform, including the new MongoDB-inspired Mango
>>> >>> feature that's now a part of CouchDB 2.0. Diana Thayer (@garbados)
>>> >>> picked up on this and built a documentation framework on top of
>>> >>> CouchApps. This, to me, is perhaps the ideal use of CouchApps:
>>> >>> unsecured content, read-only, displayed in different formats based
>>> >>> upon what the end user needs, and self-hosted by CouchDB (so you
>>> >>> can view the product's documentation using the product itself).
>>> >>> More information on this use is at:
>>> >>>
>>> >>>
>>> >>>
>>> https://mail-archives.apache.org/mod_mbox/couchdb-dev/201410.mbox/%3C28603443.66.1414446738764.JavaMail.joant@Joans-MacBook-Pro.local%3E
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> ----- Original Message -----
>>> >>>> From: "Miles Fidelman" <mf...@meetinghouse.net>
>>> >>>> To: marketing@couchdb.apache.org
>>> >>>> Sent: Friday, May 8, 2015 11:21:28 AM
>>> >>>> Subject: Re: the future of couchapp
>>> >>>>
>>> >>>> Let's be clear.
>>> >>>> (Good) marketing isn't about selling a solution to folks who don't
>>> >>>> have
>>> >>>> a problem in the first place, it's about it's identifying problems
>>> >>>> for
>>> >>>> which we offer a solution.
>>> >>>>
>>> >>>> And.. it occurs to me that Cloudant has been doing market research
>>> >>>> and
>>> >>>> "real" marketing - perhaps some folks from Cloudant might share some
>>> >>>> findings related to CouchDB (as opposed to those that might relate to
>>> >>>> their commercial extensions and services)?
>>> >>>>
>>> >>>> Miles Fidelman
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> Giovanni Lenzi wrote:
>>> >>>>>> translates user@ decisions in "how to drive them to the public"?
>>> >>>>> or maybe better how to drive dev@ implemented features to the
>>> >>>>> public ?
>>> >>>>>
>>> >>>>> 2015-05-08 16:57 GMT+02:00 Giovanni Lenzi <g....@smileupps.com>:
>>> >>>>>
>>> >>>>>> Got it, Joan. Thanks for the useful reminder, considered I am a
>>> >>>>>> total
>>> >>>>>> newbie here, I definitely don't know how decision-making process
>>> >>>>>> is driven.
>>> >>>>>>
>>> >>>>>> We will cut the "features" part from this discussion then and take
>>> >>>>>> it to
>>> >>>>>> the devs@ list
>>> >>>>>>
>>> >>>>>> Here we should then focus on @jan's request about the story for
>>> >>>>>> couchapps.. given that until 2 days ago that was somehow uncertain
>>> >>>>>>
>>> >>>>>> But I think too this is more a user@ topic... isn't maybe
>>> >>>>>> marketing more
>>> >>>>>> appropriate to translates user@ decisions in "how to drive them to
>>> >>>>>> the
>>> >>>>>> public"? If you all agree with that, you can move this discussion
>>> >>>>>> to user@
>>> >>>>>> or dev@, don't know what is preferable.
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> 2015-05-08 15:56 GMT+02:00 Joan Touzet <wo...@apache.org>:
>>> >>>>>>
>>> >>>>>>> Hi all,
>>> >>>>>>>
>>> >>>>>>> PMC hat on...
>>> >>>>>>>
>>> >>>>>>> Reminding you *again* that we should not be using the MARKETING
>>> >>>>>>> list to
>>> >>>>>>> discuss new FEATURES and functionality for Apache CouchDB. We are
>>> >>>>>>> not
>>> >>>>>>> like a company where marketing makes up what they want to do, and
>>> >>>>>>> development is forced to implement it. While it's a good idea to
>>> >>>>>>> have a
>>> >>>>>>> feedback loop between marketing and development, I am especially
>>> >>>>>>> keen to
>>> >>>>>>> not see Apache CouchDB turn into a marketing-driven development
>>> >>>>>>> effort.
>>> >>>>>>>
>>> >>>>>>> If you are proposing new CouchDB features, please make those
>>> >>>>>>> proposals
>>> >>>>>>> on the dev@ mailing list. And if you are willing to *develop* and
>>> >>>>>>> *support* those functions - even better. Current CouchDB
>>> >>>>>>> development
>>> >>>>>>> bandwidth is extremely limited, and would best be served by
>>> >>>>>>> helping you
>>> >>>>>>> to understand the current design's constraints, and the
>>> >>>>>>> difficulties
>>> >>>>>>> that may be inherent in what you ask for.
>>> >>>>>>>
>>> >>>>>>> Best regards,
>>> >>>>>>> Joan
>>> >>>>>>>
>>> >>>>>>> ----- Original Message -----
>>> >>>>>>>> From: "Giovanni Lenzi" <g....@smileupps.com>
>>> >>>>>>>> To: marketing@couchdb.apache.org
>>> >>>>>>>> Sent: Friday, May 8, 2015 4:05:12 AM
>>> >>>>>>>> Subject: Re: the future of couchapp
>>> >>>>>>>>
>>> >>>>>>>>> A service-trigger feature could be one of the new features of
>>> >>>>>>>>> Couch
>>> >>>>>>>>> apps.
>>> >>>>>>>> if possible, would be awesome :)
>>> >>>>>>>>
>>> >>>>>>>>> some clear design goals and a very limited set of features to
>>> >>>>>>>>> add
>>> >>>>>>>>> to
>>> >>>>>>>> CouchDB ddocs and focus on an in-browser tool (add features to
>>> >>>>>>>> Fauxton)
>>> >>>>>>>> that removes the need for new developers to learn git and build
>>> >>>>>>>> tools
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> --
>>> >>>>>> Giovanni Lenzi
>>> >>>>>> www.smileupps.com
>>> >>>>>> Smileupps Cloud App Store
>>> >>>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>> In theory, there is no difference between theory and practice.
>>> >>>> In practice, there is.   .... Yogi Berra
>>> >>>>
>>> >>>>
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Giovanni Lenzi
>>> >> www.smileupps.com
>>> >> Smileupps Cloud App Store
>>>
>>> --
>>> Professional Support for Apache CouchDB:
>>> http://www.neighbourhood.ie/couchdb-support/
>>>
>>>

Re: the future of couchapp

[Alexander Shorin <kx...@gmail.com>]

--
,,,^..^,,,


On Tue, May 12, 2015 at 4:48 PM, Giovanni Lenzi <g....@smileupps.com> wrote:
> Thanks Alexander for you thougths. They have been very useful for us to
> have a feeling of the current developer team status and preferences. We
> were simply not aware of such this situation.
>
> Unfortunately currently we don't have resources and erlang competences to
> join couchdb team. We have full respect for Cloudant and developers working
> in Cloudant and I understand everyone wants to work on what he cares most,
> even regardless of marketing considerations to increase interest in the
> project and ultimately the committers adoption rate.
>
> My starting intention with the thread 'couchdb articles, pills, tutorials'
> wasn't absolutely to bore anyone with such this kind of discussion. I'm
> very sorry for that, but in the end, I think it has been also useful to
> define both couchdb and smileupps' plans for the future.
>
> I'm very happy jan likes tim black's proposal to market both "couchdb" and
> "couchapps" separately and clearly, to allow them both to grow. We found it
> very very good to prevent confusion and from a marketing perspective too.
>
> Having said this, even if currently we can't do more than what we are
> already doing to grab users' interest, I'm still looking forward to work
> together with you in the future, in a way or another.
>
> Thanks all for your patience and this useful discussion,
>
> Best Regards,
>
> Smileupps Team
>
>
> Il giorno 11/mag/2015 18:47, "Jan Lehnardt" <ja...@apache.org> ha scritto:
>
>>
>> > On 11 May 2015, at 15:01, Alexander Shorin <kx...@gmail.com> wrote:
>> >
>> > Sorry, for intruding into your conversation, but let me throw you a
>> > thought I have.
>> >
>> > Apache CouchDB, as it was said, is a volunteer project, where each
>> > committer takes care about what they personally likes or need for own
>> > business: Cloudnant contributors cares about cluster feature and
>> > stable core, Jan cares about simplicity of usage CouchDB with no
>> > confusing things, Robert Kowalski like to work mostly on frontend part
>> > of the project - sorry if I didn't explain precisely position and
>> > motivation of the each, but it doesn't matter. What I want to say, is
>> > everybody works on what they likes/need/feels important.
>> >
>> > Obliviously, couchapp feature lacks of love, care and attention for
>> > quite long of time and there is no explicit leader to work on this
>> > feature and evangelist to promote. If couchapps feature is critical
>> > for Smileyupps business and they have ideas how to improve it and
>> > resources to maintain it, why not to take Cloudant as an example and
>> > become a contributor? I think, with such plan, everybody will win:
>> > CouchDB will get more powerful couchapps, Smileyupps will be able to
>> > be more attractive for their clientèle. And by the way, you eventually
>> > may help to solve confusion around couchapps.
>> >
>> > Sounds like business-driven development, but I'd like to think about
>> > it as about inventions into open source for better business. After
>> > all, business successful features mostly may receive warm welcome by a
>> > community, while business specific will get cut off in order to have
>> > more general solution that fits most in the end.
>> >
>> > Otherwise I see whole this discussion as arguing of two people where
>> > first continues keeps saying "we need couchapps! couchapps are cool!"
>> > and the second one responses "couchapps are full of flaws and
>> > confusion!". Without the one who will enter and say "Hey! Calm down,
>> > I'll sort all the problems" there wouldn't be any good solution and
>> > couchapps will die as technology by timeout: era of HTTP/2 is coming
>> > which going to change a lot of things, while I don't mention existed
>> > websockets.
>> >
>> > So what do you think about?
>>
>> I think I agree 100% with what you are saying, thanks Alexander :)
>>
>> Best
>> Jan
>> --
>>
>> >
>> > --
>> > ,,,^..^,,,
>> >
>> >
>> > On Mon, May 11, 2015 at 10:18 AM, Giovanni Lenzi <g....@smileupps.com>
>> wrote:
>> >> Hi Joan, thanks for your useful reminders. I think you hit the main
>> point.
>> >>
>> >> 2015-05-09 20:26 GMT+02:00 Joan Touzet <wo...@apache.org>:
>> >>
>> >>> *** TL;DR: the people who are willing to spend anywhere from
>> >>> thousands to millions of dollars on a CouchDB-based solution aren't
>> >>> interested in CouchApps. I think the discussion to date is missing
>> >>> this, and as such, is entirely unrepresentative of the current
>> >>> market for Apache CouchDB.
>> >>>
>> >>
>> >>
>> >>
>> >>> The answer is that there are practically no customers of Cloudant/IBM
>> >>> who are banking on CouchApps for any serious need. Every client that
>> >>> I can think of - meaning they have a dedicated cluster, and aren't
>> >>> using the shared cluster service ....
>> >>>
>> >> Cloudant built out a document-level (and field-level!) security
>> >>> solution for one customer, about two years ago now. While there was
>> >>> initial interest, performance considerations lead to the solution
>> >>> being backburnered for further consideration. Even in that situation,
>> >>> CouchApps weren't the primary concern -- database-level enforcement
>> >>> of security rules *was*.
>> >>>
>> >>
>> >> From what you cc'ed and then say, it seems that CouchDB market should be
>> >> strictly the same as Cloudant market.. Is it this what Mike and you
>> would
>> >> like to say? And if yes, why?
>> >>
>> >> Why an Apache project, should strictly target companies with thousand to
>> >> millions dollars?
>> >> Is this allowed by "the apache way"?
>> >> Are there other Apache examples of company-driven project?
>> >>
>> >> Sorry for all these questions but I am very very ignorant in this. I
>> >> thought a project should only be driven from its users as its most
>> >> important participants.
>> >>
>> >> Thanks in advance for your useful answers.
>> >>
>> >>
>> >>
>> >>>
>> >>> Within Cloudant, perhaps Simon Metson was the primary proponent of
>> >>> using CouchApps for serious purposes. He used them in the "For
>> >>> Developers" section of the website to help demonstrate various key
>> >>> features of the platform, including the new MongoDB-inspired Mango
>> >>> feature that's now a part of CouchDB 2.0. Diana Thayer (@garbados)
>> >>> picked up on this and built a documentation framework on top of
>> >>> CouchApps. This, to me, is perhaps the ideal use of CouchApps:
>> >>> unsecured content, read-only, displayed in different formats based
>> >>> upon what the end user needs, and self-hosted by CouchDB (so you
>> >>> can view the product's documentation using the product itself).
>> >>> More information on this use is at:
>> >>>
>> >>>
>> >>>
>> https://mail-archives.apache.org/mod_mbox/couchdb-dev/201410.mbox/%3C28603443.66.1414446738764.JavaMail.joant@Joans-MacBook-Pro.local%3E
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> ----- Original Message -----
>> >>>> From: "Miles Fidelman" <mf...@meetinghouse.net>
>> >>>> To: marketing@couchdb.apache.org
>> >>>> Sent: Friday, May 8, 2015 11:21:28 AM
>> >>>> Subject: Re: the future of couchapp
>> >>>>
>> >>>> Let's be clear.
>> >>>> (Good) marketing isn't about selling a solution to folks who don't
>> >>>> have
>> >>>> a problem in the first place, it's about it's identifying problems
>> >>>> for
>> >>>> which we offer a solution.
>> >>>>
>> >>>> And.. it occurs to me that Cloudant has been doing market research
>> >>>> and
>> >>>> "real" marketing - perhaps some folks from Cloudant might share some
>> >>>> findings related to CouchDB (as opposed to those that might relate to
>> >>>> their commercial extensions and services)?
>> >>>>
>> >>>> Miles Fidelman
>> >>>>
>> >>>>
>> >>>>
>> >>>> Giovanni Lenzi wrote:
>> >>>>>> translates user@ decisions in "how to drive them to the public"?
>> >>>>> or maybe better how to drive dev@ implemented features to the
>> >>>>> public ?
>> >>>>>
>> >>>>> 2015-05-08 16:57 GMT+02:00 Giovanni Lenzi <g....@smileupps.com>:
>> >>>>>
>> >>>>>> Got it, Joan. Thanks for the useful reminder, considered I am a
>> >>>>>> total
>> >>>>>> newbie here, I definitely don't know how decision-making process
>> >>>>>> is driven.
>> >>>>>>
>> >>>>>> We will cut the "features" part from this discussion then and take
>> >>>>>> it to
>> >>>>>> the devs@ list
>> >>>>>>
>> >>>>>> Here we should then focus on @jan's request about the story for
>> >>>>>> couchapps.. given that until 2 days ago that was somehow uncertain
>> >>>>>>
>> >>>>>> But I think too this is more a user@ topic... isn't maybe
>> >>>>>> marketing more
>> >>>>>> appropriate to translates user@ decisions in "how to drive them to
>> >>>>>> the
>> >>>>>> public"? If you all agree with that, you can move this discussion
>> >>>>>> to user@
>> >>>>>> or dev@, don't know what is preferable.
>> >>>>>>
>> >>>>>>
>> >>>>>> 2015-05-08 15:56 GMT+02:00 Joan Touzet <wo...@apache.org>:
>> >>>>>>
>> >>>>>>> Hi all,
>> >>>>>>>
>> >>>>>>> PMC hat on...
>> >>>>>>>
>> >>>>>>> Reminding you *again* that we should not be using the MARKETING
>> >>>>>>> list to
>> >>>>>>> discuss new FEATURES and functionality for Apache CouchDB. We are
>> >>>>>>> not
>> >>>>>>> like a company where marketing makes up what they want to do, and
>> >>>>>>> development is forced to implement it. While it's a good idea to
>> >>>>>>> have a
>> >>>>>>> feedback loop between marketing and development, I am especially
>> >>>>>>> keen to
>> >>>>>>> not see Apache CouchDB turn into a marketing-driven development
>> >>>>>>> effort.
>> >>>>>>>
>> >>>>>>> If you are proposing new CouchDB features, please make those
>> >>>>>>> proposals
>> >>>>>>> on the dev@ mailing list. And if you are willing to *develop* and
>> >>>>>>> *support* those functions - even better. Current CouchDB
>> >>>>>>> development
>> >>>>>>> bandwidth is extremely limited, and would best be served by
>> >>>>>>> helping you
>> >>>>>>> to understand the current design's constraints, and the
>> >>>>>>> difficulties
>> >>>>>>> that may be inherent in what you ask for.
>> >>>>>>>
>> >>>>>>> Best regards,
>> >>>>>>> Joan
>> >>>>>>>
>> >>>>>>> ----- Original Message -----
>> >>>>>>>> From: "Giovanni Lenzi" <g....@smileupps.com>
>> >>>>>>>> To: marketing@couchdb.apache.org
>> >>>>>>>> Sent: Friday, May 8, 2015 4:05:12 AM
>> >>>>>>>> Subject: Re: the future of couchapp
>> >>>>>>>>
>> >>>>>>>>> A service-trigger feature could be one of the new features of
>> >>>>>>>>> Couch
>> >>>>>>>>> apps.
>> >>>>>>>> if possible, would be awesome :)
>> >>>>>>>>
>> >>>>>>>>> some clear design goals and a very limited set of features to
>> >>>>>>>>> add
>> >>>>>>>>> to
>> >>>>>>>> CouchDB ddocs and focus on an in-browser tool (add features to
>> >>>>>>>> Fauxton)
>> >>>>>>>> that removes the need for new developers to learn git and build
>> >>>>>>>> tools
>> >>>>>>
>> >>>>>>
>> >>>>>> --
>> >>>>>> Giovanni Lenzi
>> >>>>>> www.smileupps.com
>> >>>>>> Smileupps Cloud App Store
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> In theory, there is no difference between theory and practice.
>> >>>> In practice, there is.   .... Yogi Berra
>> >>>>
>> >>>>
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Giovanni Lenzi
>> >> www.smileupps.com
>> >> Smileupps Cloud App Store
>>
>> --
>> Professional Support for Apache CouchDB:
>> http://www.neighbourhood.ie/couchdb-support/
>>
>>

Re: the future of couchapp

[Giovanni Lenzi <g....@smileupps.com>]

Thanks Alexander for you thougths. They have been very useful for us to
have a feeling of the current developer team status and preferences. We
were simply not aware of such this situation.

Unfortunately currently we don't have resources and erlang competences to
join couchdb team. We have full respect for Cloudant and developers working
in Cloudant and I understand everyone wants to work on what he cares most,
even regardless of marketing considerations to increase interest in the
project and ultimately the committers adoption rate.

My starting intention with the thread 'couchdb articles, pills, tutorials'
wasn't absolutely to bore anyone with such this kind of discussion. I'm
very sorry for that, but in the end, I think it has been also useful to
define both couchdb and smileupps' plans for the future.

I'm very happy jan likes tim black's proposal to market both "couchdb" and
"couchapps" separately and clearly, to allow them both to grow. We found it
very very good to prevent confusion and from a marketing perspective too.

Having said this, even if currently we can't do more than what we are
already doing to grab users' interest, I'm still looking forward to work
together with you in the future, in a way or another.

Thanks all for your patience and this useful discussion,

Best Regards,

Smileupps Team


Il giorno 11/mag/2015 18:47, "Jan Lehnardt" <ja...@apache.org> ha scritto:

>
> > On 11 May 2015, at 15:01, Alexander Shorin <kx...@gmail.com> wrote:
> >
> > Sorry, for intruding into your conversation, but let me throw you a
> > thought I have.
> >
> > Apache CouchDB, as it was said, is a volunteer project, where each
> > committer takes care about what they personally likes or need for own
> > business: Cloudnant contributors cares about cluster feature and
> > stable core, Jan cares about simplicity of usage CouchDB with no
> > confusing things, Robert Kowalski like to work mostly on frontend part
> > of the project - sorry if I didn't explain precisely position and
> > motivation of the each, but it doesn't matter. What I want to say, is
> > everybody works on what they likes/need/feels important.
> >
> > Obliviously, couchapp feature lacks of love, care and attention for
> > quite long of time and there is no explicit leader to work on this
> > feature and evangelist to promote. If couchapps feature is critical
> > for Smileyupps business and they have ideas how to improve it and
> > resources to maintain it, why not to take Cloudant as an example and
> > become a contributor? I think, with such plan, everybody will win:
> > CouchDB will get more powerful couchapps, Smileyupps will be able to
> > be more attractive for their clientèle. And by the way, you eventually
> > may help to solve confusion around couchapps.
> >
> > Sounds like business-driven development, but I'd like to think about
> > it as about inventions into open source for better business. After
> > all, business successful features mostly may receive warm welcome by a
> > community, while business specific will get cut off in order to have
> > more general solution that fits most in the end.
> >
> > Otherwise I see whole this discussion as arguing of two people where
> > first continues keeps saying "we need couchapps! couchapps are cool!"
> > and the second one responses "couchapps are full of flaws and
> > confusion!". Without the one who will enter and say "Hey! Calm down,
> > I'll sort all the problems" there wouldn't be any good solution and
> > couchapps will die as technology by timeout: era of HTTP/2 is coming
> > which going to change a lot of things, while I don't mention existed
> > websockets.
> >
> > So what do you think about?
>
> I think I agree 100% with what you are saying, thanks Alexander :)
>
> Best
> Jan
> --
>
> >
> > --
> > ,,,^..^,,,
> >
> >
> > On Mon, May 11, 2015 at 10:18 AM, Giovanni Lenzi <g....@smileupps.com>
> wrote:
> >> Hi Joan, thanks for your useful reminders. I think you hit the main
> point.
> >>
> >> 2015-05-09 20:26 GMT+02:00 Joan Touzet <wo...@apache.org>:
> >>
> >>> *** TL;DR: the people who are willing to spend anywhere from
> >>> thousands to millions of dollars on a CouchDB-based solution aren't
> >>> interested in CouchApps. I think the discussion to date is missing
> >>> this, and as such, is entirely unrepresentative of the current
> >>> market for Apache CouchDB.
> >>>
> >>
> >>
> >>
> >>> The answer is that there are practically no customers of Cloudant/IBM
> >>> who are banking on CouchApps for any serious need. Every client that
> >>> I can think of - meaning they have a dedicated cluster, and aren't
> >>> using the shared cluster service ....
> >>>
> >> Cloudant built out a document-level (and field-level!) security
> >>> solution for one customer, about two years ago now. While there was
> >>> initial interest, performance considerations lead to the solution
> >>> being backburnered for further consideration. Even in that situation,
> >>> CouchApps weren't the primary concern -- database-level enforcement
> >>> of security rules *was*.
> >>>
> >>
> >> From what you cc'ed and then say, it seems that CouchDB market should be
> >> strictly the same as Cloudant market.. Is it this what Mike and you
> would
> >> like to say? And if yes, why?
> >>
> >> Why an Apache project, should strictly target companies with thousand to
> >> millions dollars?
> >> Is this allowed by "the apache way"?
> >> Are there other Apache examples of company-driven project?
> >>
> >> Sorry for all these questions but I am very very ignorant in this. I
> >> thought a project should only be driven from its users as its most
> >> important participants.
> >>
> >> Thanks in advance for your useful answers.
> >>
> >>
> >>
> >>>
> >>> Within Cloudant, perhaps Simon Metson was the primary proponent of
> >>> using CouchApps for serious purposes. He used them in the "For
> >>> Developers" section of the website to help demonstrate various key
> >>> features of the platform, including the new MongoDB-inspired Mango
> >>> feature that's now a part of CouchDB 2.0. Diana Thayer (@garbados)
> >>> picked up on this and built a documentation framework on top of
> >>> CouchApps. This, to me, is perhaps the ideal use of CouchApps:
> >>> unsecured content, read-only, displayed in different formats based
> >>> upon what the end user needs, and self-hosted by CouchDB (so you
> >>> can view the product's documentation using the product itself).
> >>> More information on this use is at:
> >>>
> >>>
> >>>
> https://mail-archives.apache.org/mod_mbox/couchdb-dev/201410.mbox/%3C28603443.66.1414446738764.JavaMail.joant@Joans-MacBook-Pro.local%3E
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Miles Fidelman" <mf...@meetinghouse.net>
> >>>> To: marketing@couchdb.apache.org
> >>>> Sent: Friday, May 8, 2015 11:21:28 AM
> >>>> Subject: Re: the future of couchapp
> >>>>
> >>>> Let's be clear.
> >>>> (Good) marketing isn't about selling a solution to folks who don't
> >>>> have
> >>>> a problem in the first place, it's about it's identifying problems
> >>>> for
> >>>> which we offer a solution.
> >>>>
> >>>> And.. it occurs to me that Cloudant has been doing market research
> >>>> and
> >>>> "real" marketing - perhaps some folks from Cloudant might share some
> >>>> findings related to CouchDB (as opposed to those that might relate to
> >>>> their commercial extensions and services)?
> >>>>
> >>>> Miles Fidelman
> >>>>
> >>>>
> >>>>
> >>>> Giovanni Lenzi wrote:
> >>>>>> translates user@ decisions in "how to drive them to the public"?
> >>>>> or maybe better how to drive dev@ implemented features to the
> >>>>> public ?
> >>>>>
> >>>>> 2015-05-08 16:57 GMT+02:00 Giovanni Lenzi <g....@smileupps.com>:
> >>>>>
> >>>>>> Got it, Joan. Thanks for the useful reminder, considered I am a
> >>>>>> total
> >>>>>> newbie here, I definitely don't know how decision-making process
> >>>>>> is driven.
> >>>>>>
> >>>>>> We will cut the "features" part from this discussion then and take
> >>>>>> it to
> >>>>>> the devs@ list
> >>>>>>
> >>>>>> Here we should then focus on @jan's request about the story for
> >>>>>> couchapps.. given that until 2 days ago that was somehow uncertain
> >>>>>>
> >>>>>> But I think too this is more a user@ topic... isn't maybe
> >>>>>> marketing more
> >>>>>> appropriate to translates user@ decisions in "how to drive them to
> >>>>>> the
> >>>>>> public"? If you all agree with that, you can move this discussion
> >>>>>> to user@
> >>>>>> or dev@, don't know what is preferable.
> >>>>>>
> >>>>>>
> >>>>>> 2015-05-08 15:56 GMT+02:00 Joan Touzet <wo...@apache.org>:
> >>>>>>
> >>>>>>> Hi all,
> >>>>>>>
> >>>>>>> PMC hat on...
> >>>>>>>
> >>>>>>> Reminding you *again* that we should not be using the MARKETING
> >>>>>>> list to
> >>>>>>> discuss new FEATURES and functionality for Apache CouchDB. We are
> >>>>>>> not
> >>>>>>> like a company where marketing makes up what they want to do, and
> >>>>>>> development is forced to implement it. While it's a good idea to
> >>>>>>> have a
> >>>>>>> feedback loop between marketing and development, I am especially
> >>>>>>> keen to
> >>>>>>> not see Apache CouchDB turn into a marketing-driven development
> >>>>>>> effort.
> >>>>>>>
> >>>>>>> If you are proposing new CouchDB features, please make those
> >>>>>>> proposals
> >>>>>>> on the dev@ mailing list. And if you are willing to *develop* and
> >>>>>>> *support* those functions - even better. Current CouchDB
> >>>>>>> development
> >>>>>>> bandwidth is extremely limited, and would best be served by
> >>>>>>> helping you
> >>>>>>> to understand the current design's constraints, and the
> >>>>>>> difficulties
> >>>>>>> that may be inherent in what you ask for.
> >>>>>>>
> >>>>>>> Best regards,
> >>>>>>> Joan
> >>>>>>>
> >>>>>>> ----- Original Message -----
> >>>>>>>> From: "Giovanni Lenzi" <g....@smileupps.com>
> >>>>>>>> To: marketing@couchdb.apache.org
> >>>>>>>> Sent: Friday, May 8, 2015 4:05:12 AM
> >>>>>>>> Subject: Re: the future of couchapp
> >>>>>>>>
> >>>>>>>>> A service-trigger feature could be one of the new features of
> >>>>>>>>> Couch
> >>>>>>>>> apps.
> >>>>>>>> if possible, would be awesome :)
> >>>>>>>>
> >>>>>>>>> some clear design goals and a very limited set of features to
> >>>>>>>>> add
> >>>>>>>>> to
> >>>>>>>> CouchDB ddocs and focus on an in-browser tool (add features to
> >>>>>>>> Fauxton)
> >>>>>>>> that removes the need for new developers to learn git and build
> >>>>>>>> tools
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Giovanni Lenzi
> >>>>>> www.smileupps.com
> >>>>>> Smileupps Cloud App Store
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> In theory, there is no difference between theory and practice.
> >>>> In practice, there is.   .... Yogi Berra
> >>>>
> >>>>
> >>>
> >>
> >>
> >>
> >> --
> >> Giovanni Lenzi
> >> www.smileupps.com
> >> Smileupps Cloud App Store
>
> --
> Professional Support for Apache CouchDB:
> http://www.neighbourhood.ie/couchdb-support/
>
>

Re: the future of couchapp

[Jan Lehnardt <ja...@apache.org>]

> On 11 May 2015, at 15:01, Alexander Shorin <kx...@gmail.com> wrote:
> 
> Sorry, for intruding into your conversation, but let me throw you a
> thought I have.
> 
> Apache CouchDB, as it was said, is a volunteer project, where each
> committer takes care about what they personally likes or need for own
> business: Cloudnant contributors cares about cluster feature and
> stable core, Jan cares about simplicity of usage CouchDB with no
> confusing things, Robert Kowalski like to work mostly on frontend part
> of the project - sorry if I didn't explain precisely position and
> motivation of the each, but it doesn't matter. What I want to say, is
> everybody works on what they likes/need/feels important.
> 
> Obliviously, couchapp feature lacks of love, care and attention for
> quite long of time and there is no explicit leader to work on this
> feature and evangelist to promote. If couchapps feature is critical
> for Smileyupps business and they have ideas how to improve it and
> resources to maintain it, why not to take Cloudant as an example and
> become a contributor? I think, with such plan, everybody will win:
> CouchDB will get more powerful couchapps, Smileyupps will be able to
> be more attractive for their clientèle. And by the way, you eventually
> may help to solve confusion around couchapps.
> 
> Sounds like business-driven development, but I'd like to think about
> it as about inventions into open source for better business. After
> all, business successful features mostly may receive warm welcome by a
> community, while business specific will get cut off in order to have
> more general solution that fits most in the end.
> 
> Otherwise I see whole this discussion as arguing of two people where
> first continues keeps saying "we need couchapps! couchapps are cool!"
> and the second one responses "couchapps are full of flaws and
> confusion!". Without the one who will enter and say "Hey! Calm down,
> I'll sort all the problems" there wouldn't be any good solution and
> couchapps will die as technology by timeout: era of HTTP/2 is coming
> which going to change a lot of things, while I don't mention existed
> websockets.
> 
> So what do you think about?

I think I agree 100% with what you are saying, thanks Alexander :)

Best
Jan
-- 

> 
> --
> ,,,^..^,,,
> 
> 
> On Mon, May 11, 2015 at 10:18 AM, Giovanni Lenzi <g....@smileupps.com> wrote:
>> Hi Joan, thanks for your useful reminders. I think you hit the main point.
>> 
>> 2015-05-09 20:26 GMT+02:00 Joan Touzet <wo...@apache.org>:
>> 
>>> *** TL;DR: the people who are willing to spend anywhere from
>>> thousands to millions of dollars on a CouchDB-based solution aren't
>>> interested in CouchApps. I think the discussion to date is missing
>>> this, and as such, is entirely unrepresentative of the current
>>> market for Apache CouchDB.
>>> 
>> 
>> 
>> 
>>> The answer is that there are practically no customers of Cloudant/IBM
>>> who are banking on CouchApps for any serious need. Every client that
>>> I can think of - meaning they have a dedicated cluster, and aren't
>>> using the shared cluster service ....
>>> 
>> Cloudant built out a document-level (and field-level!) security
>>> solution for one customer, about two years ago now. While there was
>>> initial interest, performance considerations lead to the solution
>>> being backburnered for further consideration. Even in that situation,
>>> CouchApps weren't the primary concern -- database-level enforcement
>>> of security rules *was*.
>>> 
>> 
>> From what you cc'ed and then say, it seems that CouchDB market should be
>> strictly the same as Cloudant market.. Is it this what Mike and you would
>> like to say? And if yes, why?
>> 
>> Why an Apache project, should strictly target companies with thousand to
>> millions dollars?
>> Is this allowed by "the apache way"?
>> Are there other Apache examples of company-driven project?
>> 
>> Sorry for all these questions but I am very very ignorant in this. I
>> thought a project should only be driven from its users as its most
>> important participants.
>> 
>> Thanks in advance for your useful answers.
>> 
>> 
>> 
>>> 
>>> Within Cloudant, perhaps Simon Metson was the primary proponent of
>>> using CouchApps for serious purposes. He used them in the "For
>>> Developers" section of the website to help demonstrate various key
>>> features of the platform, including the new MongoDB-inspired Mango
>>> feature that's now a part of CouchDB 2.0. Diana Thayer (@garbados)
>>> picked up on this and built a documentation framework on top of
>>> CouchApps. This, to me, is perhaps the ideal use of CouchApps:
>>> unsecured content, read-only, displayed in different formats based
>>> upon what the end user needs, and self-hosted by CouchDB (so you
>>> can view the product's documentation using the product itself).
>>> More information on this use is at:
>>> 
>>> 
>>> https://mail-archives.apache.org/mod_mbox/couchdb-dev/201410.mbox/%3C28603443.66.1414446738764.JavaMail.joant@Joans-MacBook-Pro.local%3E
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ----- Original Message -----
>>>> From: "Miles Fidelman" <mf...@meetinghouse.net>
>>>> To: marketing@couchdb.apache.org
>>>> Sent: Friday, May 8, 2015 11:21:28 AM
>>>> Subject: Re: the future of couchapp
>>>> 
>>>> Let's be clear.
>>>> (Good) marketing isn't about selling a solution to folks who don't
>>>> have
>>>> a problem in the first place, it's about it's identifying problems
>>>> for
>>>> which we offer a solution.
>>>> 
>>>> And.. it occurs to me that Cloudant has been doing market research
>>>> and
>>>> "real" marketing - perhaps some folks from Cloudant might share some
>>>> findings related to CouchDB (as opposed to those that might relate to
>>>> their commercial extensions and services)?
>>>> 
>>>> Miles Fidelman
>>>> 
>>>> 
>>>> 
>>>> Giovanni Lenzi wrote:
>>>>>> translates user@ decisions in "how to drive them to the public"?
>>>>> or maybe better how to drive dev@ implemented features to the
>>>>> public ?
>>>>> 
>>>>> 2015-05-08 16:57 GMT+02:00 Giovanni Lenzi <g....@smileupps.com>:
>>>>> 
>>>>>> Got it, Joan. Thanks for the useful reminder, considered I am a
>>>>>> total
>>>>>> newbie here, I definitely don't know how decision-making process
>>>>>> is driven.
>>>>>> 
>>>>>> We will cut the "features" part from this discussion then and take
>>>>>> it to
>>>>>> the devs@ list
>>>>>> 
>>>>>> Here we should then focus on @jan's request about the story for
>>>>>> couchapps.. given that until 2 days ago that was somehow uncertain
>>>>>> 
>>>>>> But I think too this is more a user@ topic... isn't maybe
>>>>>> marketing more
>>>>>> appropriate to translates user@ decisions in "how to drive them to
>>>>>> the
>>>>>> public"? If you all agree with that, you can move this discussion
>>>>>> to user@
>>>>>> or dev@, don't know what is preferable.
>>>>>> 
>>>>>> 
>>>>>> 2015-05-08 15:56 GMT+02:00 Joan Touzet <wo...@apache.org>:
>>>>>> 
>>>>>>> Hi all,
>>>>>>> 
>>>>>>> PMC hat on...
>>>>>>> 
>>>>>>> Reminding you *again* that we should not be using the MARKETING
>>>>>>> list to
>>>>>>> discuss new FEATURES and functionality for Apache CouchDB. We are
>>>>>>> not
>>>>>>> like a company where marketing makes up what they want to do, and
>>>>>>> development is forced to implement it. While it's a good idea to
>>>>>>> have a
>>>>>>> feedback loop between marketing and development, I am especially
>>>>>>> keen to
>>>>>>> not see Apache CouchDB turn into a marketing-driven development
>>>>>>> effort.
>>>>>>> 
>>>>>>> If you are proposing new CouchDB features, please make those
>>>>>>> proposals
>>>>>>> on the dev@ mailing list. And if you are willing to *develop* and
>>>>>>> *support* those functions - even better. Current CouchDB
>>>>>>> development
>>>>>>> bandwidth is extremely limited, and would best be served by
>>>>>>> helping you
>>>>>>> to understand the current design's constraints, and the
>>>>>>> difficulties
>>>>>>> that may be inherent in what you ask for.
>>>>>>> 
>>>>>>> Best regards,
>>>>>>> Joan
>>>>>>> 
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Giovanni Lenzi" <g....@smileupps.com>
>>>>>>>> To: marketing@couchdb.apache.org
>>>>>>>> Sent: Friday, May 8, 2015 4:05:12 AM
>>>>>>>> Subject: Re: the future of couchapp
>>>>>>>> 
>>>>>>>>> A service-trigger feature could be one of the new features of
>>>>>>>>> Couch
>>>>>>>>> apps.
>>>>>>>> if possible, would be awesome :)
>>>>>>>> 
>>>>>>>>> some clear design goals and a very limited set of features to
>>>>>>>>> add
>>>>>>>>> to
>>>>>>>> CouchDB ddocs and focus on an in-browser tool (add features to
>>>>>>>> Fauxton)
>>>>>>>> that removes the need for new developers to learn git and build
>>>>>>>> tools
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Giovanni Lenzi
>>>>>> www.smileupps.com
>>>>>> Smileupps Cloud App Store
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> In theory, there is no difference between theory and practice.
>>>> In practice, there is.   .... Yogi Berra
>>>> 
>>>> 
>>> 
>> 
>> 
>> 
>> --
>> Giovanni Lenzi
>> www.smileupps.com
>> Smileupps Cloud App Store

-- 
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/

Re: the future of couchapp

[Alexander Shorin <kx...@gmail.com>]

Sorry, for intruding into your conversation, but let me throw you a
thought I have.

Apache CouchDB, as it was said, is a volunteer project, where each
committer takes care about what they personally likes or need for own
business: Cloudnant contributors cares about cluster feature and
stable core, Jan cares about simplicity of usage CouchDB with no
confusing things, Robert Kowalski like to work mostly on frontend part
of the project - sorry if I didn't explain precisely position and
motivation of the each, but it doesn't matter. What I want to say, is
everybody works on what they likes/need/feels important.

Obliviously, couchapp feature lacks of love, care and attention for
quite long of time and there is no explicit leader to work on this
feature and evangelist to promote. If couchapps feature is critical
for Smileyupps business and they have ideas how to improve it and
resources to maintain it, why not to take Cloudant as an example and
become a contributor? I think, with such plan, everybody will win:
CouchDB will get more powerful couchapps, Smileyupps will be able to
be more attractive for their clientèle. And by the way, you eventually
may help to solve confusion around couchapps.

Sounds like business-driven development, but I'd like to think about
it as about inventions into open source for better business. After
all, business successful features mostly may receive warm welcome by a
community, while business specific will get cut off in order to have
more general solution that fits most in the end.

Otherwise I see whole this discussion as arguing of two people where
first continues keeps saying "we need couchapps! couchapps are cool!"
and the second one responses "couchapps are full of flaws and
confusion!". Without the one who will enter and say "Hey! Calm down,
I'll sort all the problems" there wouldn't be any good solution and
couchapps will die as technology by timeout: era of HTTP/2 is coming
which going to change a lot of things, while I don't mention existed
websockets.

So what do you think about?

--
,,,^..^,,,


On Mon, May 11, 2015 at 10:18 AM, Giovanni Lenzi <g....@smileupps.com> wrote:
> Hi Joan, thanks for your useful reminders. I think you hit the main point.
>
> 2015-05-09 20:26 GMT+02:00 Joan Touzet <wo...@apache.org>:
>
>> *** TL;DR: the people who are willing to spend anywhere from
>> thousands to millions of dollars on a CouchDB-based solution aren't
>> interested in CouchApps. I think the discussion to date is missing
>> this, and as such, is entirely unrepresentative of the current
>> market for Apache CouchDB.
>>
>
>
>
>> The answer is that there are practically no customers of Cloudant/IBM
>> who are banking on CouchApps for any serious need. Every client that
>> I can think of - meaning they have a dedicated cluster, and aren't
>> using the shared cluster service ....
>>
> Cloudant built out a document-level (and field-level!) security
>> solution for one customer, about two years ago now. While there was
>> initial interest, performance considerations lead to the solution
>> being backburnered for further consideration. Even in that situation,
>> CouchApps weren't the primary concern -- database-level enforcement
>> of security rules *was*.
>>
>
> From what you cc'ed and then say, it seems that CouchDB market should be
> strictly the same as Cloudant market.. Is it this what Mike and you would
> like to say? And if yes, why?
>
> Why an Apache project, should strictly target companies with thousand to
> millions dollars?
> Is this allowed by "the apache way"?
> Are there other Apache examples of company-driven project?
>
> Sorry for all these questions but I am very very ignorant in this. I
> thought a project should only be driven from its users as its most
> important participants.
>
> Thanks in advance for your useful answers.
>
>
>
>>
>> Within Cloudant, perhaps Simon Metson was the primary proponent of
>> using CouchApps for serious purposes. He used them in the "For
>> Developers" section of the website to help demonstrate various key
>> features of the platform, including the new MongoDB-inspired Mango
>> feature that's now a part of CouchDB 2.0. Diana Thayer (@garbados)
>> picked up on this and built a documentation framework on top of
>> CouchApps. This, to me, is perhaps the ideal use of CouchApps:
>> unsecured content, read-only, displayed in different formats based
>> upon what the end user needs, and self-hosted by CouchDB (so you
>> can view the product's documentation using the product itself).
>> More information on this use is at:
>>
>>
>> https://mail-archives.apache.org/mod_mbox/couchdb-dev/201410.mbox/%3C28603443.66.1414446738764.JavaMail.joant@Joans-MacBook-Pro.local%3E
>>
>>
>>
>>
>>
>> ----- Original Message -----
>> > From: "Miles Fidelman" <mf...@meetinghouse.net>
>> > To: marketing@couchdb.apache.org
>> > Sent: Friday, May 8, 2015 11:21:28 AM
>> > Subject: Re: the future of couchapp
>> >
>> > Let's be clear.
>> > (Good) marketing isn't about selling a solution to folks who don't
>> > have
>> > a problem in the first place, it's about it's identifying problems
>> > for
>> > which we offer a solution.
>> >
>> > And.. it occurs to me that Cloudant has been doing market research
>> > and
>> > "real" marketing - perhaps some folks from Cloudant might share some
>> > findings related to CouchDB (as opposed to those that might relate to
>> > their commercial extensions and services)?
>> >
>> > Miles Fidelman
>> >
>> >
>> >
>> > Giovanni Lenzi wrote:
>> > >> translates user@ decisions in "how to drive them to the public"?
>> > > or maybe better how to drive dev@ implemented features to the
>> > > public ?
>> > >
>> > > 2015-05-08 16:57 GMT+02:00 Giovanni Lenzi <g....@smileupps.com>:
>> > >
>> > >> Got it, Joan. Thanks for the useful reminder, considered I am a
>> > >> total
>> > >> newbie here, I definitely don't know how decision-making process
>> > >> is driven.
>> > >>
>> > >> We will cut the "features" part from this discussion then and take
>> > >> it to
>> > >> the devs@ list
>> > >>
>> > >> Here we should then focus on @jan's request about the story for
>> > >> couchapps.. given that until 2 days ago that was somehow uncertain
>> > >>
>> > >> But I think too this is more a user@ topic... isn't maybe
>> > >> marketing more
>> > >> appropriate to translates user@ decisions in "how to drive them to
>> > >> the
>> > >> public"? If you all agree with that, you can move this discussion
>> > >> to user@
>> > >> or dev@, don't know what is preferable.
>> > >>
>> > >>
>> > >> 2015-05-08 15:56 GMT+02:00 Joan Touzet <wo...@apache.org>:
>> > >>
>> > >>> Hi all,
>> > >>>
>> > >>> PMC hat on...
>> > >>>
>> > >>> Reminding you *again* that we should not be using the MARKETING
>> > >>> list to
>> > >>> discuss new FEATURES and functionality for Apache CouchDB. We are
>> > >>> not
>> > >>> like a company where marketing makes up what they want to do, and
>> > >>> development is forced to implement it. While it's a good idea to
>> > >>> have a
>> > >>> feedback loop between marketing and development, I am especially
>> > >>> keen to
>> > >>> not see Apache CouchDB turn into a marketing-driven development
>> > >>> effort.
>> > >>>
>> > >>> If you are proposing new CouchDB features, please make those
>> > >>> proposals
>> > >>> on the dev@ mailing list. And if you are willing to *develop* and
>> > >>> *support* those functions - even better. Current CouchDB
>> > >>> development
>> > >>> bandwidth is extremely limited, and would best be served by
>> > >>> helping you
>> > >>> to understand the current design's constraints, and the
>> > >>> difficulties
>> > >>> that may be inherent in what you ask for.
>> > >>>
>> > >>> Best regards,
>> > >>> Joan
>> > >>>
>> > >>> ----- Original Message -----
>> > >>>> From: "Giovanni Lenzi" <g....@smileupps.com>
>> > >>>> To: marketing@couchdb.apache.org
>> > >>>> Sent: Friday, May 8, 2015 4:05:12 AM
>> > >>>> Subject: Re: the future of couchapp
>> > >>>>
>> > >>>>> A service-trigger feature could be one of the new features of
>> > >>>>> Couch
>> > >>>>> apps.
>> > >>>> if possible, would be awesome :)
>> > >>>>
>> > >>>>> some clear design goals and a very limited set of features to
>> > >>>>> add
>> > >>>>> to
>> > >>>> CouchDB ddocs and focus on an in-browser tool (add features to
>> > >>>> Fauxton)
>> > >>>> that removes the need for new developers to learn git and build
>> > >>>> tools
>> > >>
>> > >>
>> > >> --
>> > >> Giovanni Lenzi
>> > >> www.smileupps.com
>> > >> Smileupps Cloud App Store
>> > >>
>> > >
>> > >
>> >
>> >
>> > --
>> > In theory, there is no difference between theory and practice.
>> > In practice, there is.   .... Yogi Berra
>> >
>> >
>>
>
>
>
> --
> Giovanni Lenzi
> www.smileupps.com
> Smileupps Cloud App Store

Re: the future of couchapp

[Giovanni Lenzi <g....@smileupps.com>]

Hi Joan, thanks for your useful reminders. I think you hit the main point.

2015-05-09 20:26 GMT+02:00 Joan Touzet <wo...@apache.org>:

> *** TL;DR: the people who are willing to spend anywhere from
> thousands to millions of dollars on a CouchDB-based solution aren't
> interested in CouchApps. I think the discussion to date is missing
> this, and as such, is entirely unrepresentative of the current
> market for Apache CouchDB.
>



> The answer is that there are practically no customers of Cloudant/IBM
> who are banking on CouchApps for any serious need. Every client that
> I can think of - meaning they have a dedicated cluster, and aren't
> using the shared cluster service ....
>
Cloudant built out a document-level (and field-level!) security
> solution for one customer, about two years ago now. While there was
> initial interest, performance considerations lead to the solution
> being backburnered for further consideration. Even in that situation,
> CouchApps weren't the primary concern -- database-level enforcement
> of security rules *was*.
>

>From what you cc'ed and then say, it seems that CouchDB market should be
strictly the same as Cloudant market.. Is it this what Mike and you would
like to say? And if yes, why?

Why an Apache project, should strictly target companies with thousand to
millions dollars?
Is this allowed by "the apache way"?
Are there other Apache examples of company-driven project?

Sorry for all these questions but I am very very ignorant in this. I
thought a project should only be driven from its users as its most
important participants.

Thanks in advance for your useful answers.



>
> Within Cloudant, perhaps Simon Metson was the primary proponent of
> using CouchApps for serious purposes. He used them in the "For
> Developers" section of the website to help demonstrate various key
> features of the platform, including the new MongoDB-inspired Mango
> feature that's now a part of CouchDB 2.0. Diana Thayer (@garbados)
> picked up on this and built a documentation framework on top of
> CouchApps. This, to me, is perhaps the ideal use of CouchApps:
> unsecured content, read-only, displayed in different formats based
> upon what the end user needs, and self-hosted by CouchDB (so you
> can view the product's documentation using the product itself).
> More information on this use is at:
>
>
> https://mail-archives.apache.org/mod_mbox/couchdb-dev/201410.mbox/%3C28603443.66.1414446738764.JavaMail.joant@Joans-MacBook-Pro.local%3E
>
>
>
>
>
> ----- Original Message -----
> > From: "Miles Fidelman" <mf...@meetinghouse.net>
> > To: marketing@couchdb.apache.org
> > Sent: Friday, May 8, 2015 11:21:28 AM
> > Subject: Re: the future of couchapp
> >
> > Let's be clear.
> > (Good) marketing isn't about selling a solution to folks who don't
> > have
> > a problem in the first place, it's about it's identifying problems
> > for
> > which we offer a solution.
> >
> > And.. it occurs to me that Cloudant has been doing market research
> > and
> > "real" marketing - perhaps some folks from Cloudant might share some
> > findings related to CouchDB (as opposed to those that might relate to
> > their commercial extensions and services)?
> >
> > Miles Fidelman
> >
> >
> >
> > Giovanni Lenzi wrote:
> > >> translates user@ decisions in "how to drive them to the public"?
> > > or maybe better how to drive dev@ implemented features to the
> > > public ?
> > >
> > > 2015-05-08 16:57 GMT+02:00 Giovanni Lenzi <g....@smileupps.com>:
> > >
> > >> Got it, Joan. Thanks for the useful reminder, considered I am a
> > >> total
> > >> newbie here, I definitely don't know how decision-making process
> > >> is driven.
> > >>
> > >> We will cut the "features" part from this discussion then and take
> > >> it to
> > >> the devs@ list
> > >>
> > >> Here we should then focus on @jan's request about the story for
> > >> couchapps.. given that until 2 days ago that was somehow uncertain
> > >>
> > >> But I think too this is more a user@ topic... isn't maybe
> > >> marketing more
> > >> appropriate to translates user@ decisions in "how to drive them to
> > >> the
> > >> public"? If you all agree with that, you can move this discussion
> > >> to user@
> > >> or dev@, don't know what is preferable.
> > >>
> > >>
> > >> 2015-05-08 15:56 GMT+02:00 Joan Touzet <wo...@apache.org>:
> > >>
> > >>> Hi all,
> > >>>
> > >>> PMC hat on...
> > >>>
> > >>> Reminding you *again* that we should not be using the MARKETING
> > >>> list to
> > >>> discuss new FEATURES and functionality for Apache CouchDB. We are
> > >>> not
> > >>> like a company where marketing makes up what they want to do, and
> > >>> development is forced to implement it. While it's a good idea to
> > >>> have a
> > >>> feedback loop between marketing and development, I am especially
> > >>> keen to
> > >>> not see Apache CouchDB turn into a marketing-driven development
> > >>> effort.
> > >>>
> > >>> If you are proposing new CouchDB features, please make those
> > >>> proposals
> > >>> on the dev@ mailing list. And if you are willing to *develop* and
> > >>> *support* those functions - even better. Current CouchDB
> > >>> development
> > >>> bandwidth is extremely limited, and would best be served by
> > >>> helping you
> > >>> to understand the current design's constraints, and the
> > >>> difficulties
> > >>> that may be inherent in what you ask for.
> > >>>
> > >>> Best regards,
> > >>> Joan
> > >>>
> > >>> ----- Original Message -----
> > >>>> From: "Giovanni Lenzi" <g....@smileupps.com>
> > >>>> To: marketing@couchdb.apache.org
> > >>>> Sent: Friday, May 8, 2015 4:05:12 AM
> > >>>> Subject: Re: the future of couchapp
> > >>>>
> > >>>>> A service-trigger feature could be one of the new features of
> > >>>>> Couch
> > >>>>> apps.
> > >>>> if possible, would be awesome :)
> > >>>>
> > >>>>> some clear design goals and a very limited set of features to
> > >>>>> add
> > >>>>> to
> > >>>> CouchDB ddocs and focus on an in-browser tool (add features to
> > >>>> Fauxton)
> > >>>> that removes the need for new developers to learn git and build
> > >>>> tools
> > >>
> > >>
> > >> --
> > >> Giovanni Lenzi
> > >> www.smileupps.com
> > >> Smileupps Cloud App Store
> > >>
> > >
> > >
> >
> >
> > --
> > In theory, there is no difference between theory and practice.
> > In practice, there is.   .... Yogi Berra
> >
> >
>



-- 
Giovanni Lenzi
www.smileupps.com
Smileupps Cloud App Store

Re: the future of couchapp

[Miles Fidelman <mf...@meetinghouse.net>]

Joan,

Thanks for the datapoints!

I am a little surprised, though - I'd think that simple, 
data-driven-documents (particularly visualizations), implemented as 
CouchApps, would be just the thing for anyone who is using Cloudant for 
storing and mining large databases.

Just a thought.

Cheers,

Miles

Joan Touzet wrote:
> Hi Miles,
>
> DISCLAIMER: I am not speaking as an official representative of IBM or
> Cloudant. I have cc'ed Mike Broberg, who can speak for them if
> necessary. (I also want him to be aware of what I am saying here).
>
> *** TL;DR: the people who are willing to spend anywhere from
> thousands to millions of dollars on a CouchDB-based solution aren't
> interested in CouchApps. I think the discussion to date is missing
> this, and as such, is entirely unrepresentative of the current
> market for Apache CouchDB.
>
> The answer is that there are practically no customers of Cloudant/IBM
> who are banking on CouchApps for any serious need. Every client that
> I can think of - meaning they have a dedicated cluster, and aren't
> using the shared cluster service - are using either a traditional
> three-tier app server structure (Node.JS, Python, PHP, Ruby, Java,
> .NET, etc.) or are doing client-side development on mobile platforms
> (iOS + TouchDB, Android + PouchDB) where they are replicating back to
> the Cloudant clusters for data exchange. In all of these scenarios,
> replication is the "killer feature" for CouchDB, with the REST
> interface a close second, and the ease of unstructured JSON data as
> a third.
>
> Cloudant built out a document-level (and field-level!) security
> solution for one customer, about two years ago now. While there was
> initial interest, performance considerations lead to the solution
> being backburnered for further consideration. Even in that situation,
> CouchApps weren't the primary concern -- database-level enforcement
> of security rules *was*.
>
> Within Cloudant, perhaps Simon Metson was the primary proponent of
> using CouchApps for serious purposes. He used them in the "For
> Developers" section of the website to help demonstrate various key
> features of the platform, including the new MongoDB-inspired Mango
> feature that's now a part of CouchDB 2.0. Diana Thayer (@garbados)
> picked up on this and built a documentation framework on top of
> CouchApps. This, to me, is perhaps the ideal use of CouchApps:
> unsecured content, read-only, displayed in different formats based
> upon what the end user needs, and self-hosted by CouchDB (so you
> can view the product's documentation using the product itself).
> More information on this use is at:
>
> https://mail-archives.apache.org/mod_mbox/couchdb-dev/201410.mbox/%3C28603443.66.1414446738764.JavaMail.joant@Joans-MacBook-Pro.local%3E
>
>
>
>
>
> ----- Original Message -----
>> From: "Miles Fidelman" <mf...@meetinghouse.net>
>> To: marketing@couchdb.apache.org
>> Sent: Friday, May 8, 2015 11:21:28 AM
>> Subject: Re: the future of couchapp
>>
>> Let's be clear.
>> (Good) marketing isn't about selling a solution to folks who don't
>> have
>> a problem in the first place, it's about it's identifying problems
>> for
>> which we offer a solution.
>>
>> And.. it occurs to me that Cloudant has been doing market research
>> and
>> "real" marketing - perhaps some folks from Cloudant might share some
>> findings related to CouchDB (as opposed to those that might relate to
>> their commercial extensions and services)?
>>
>> Miles Fidelman
>>
>>
>>
>> Giovanni Lenzi wrote:
>>>> translates user@ decisions in "how to drive them to the public"?
>>> or maybe better how to drive dev@ implemented features to the
>>> public ?
>>>
>>> 2015-05-08 16:57 GMT+02:00 Giovanni Lenzi <g....@smileupps.com>:
>>>
>>>> Got it, Joan. Thanks for the useful reminder, considered I am a
>>>> total
>>>> newbie here, I definitely don't know how decision-making process
>>>> is driven.
>>>>
>>>> We will cut the "features" part from this discussion then and take
>>>> it to
>>>> the devs@ list
>>>>
>>>> Here we should then focus on @jan's request about the story for
>>>> couchapps.. given that until 2 days ago that was somehow uncertain
>>>>
>>>> But I think too this is more a user@ topic... isn't maybe
>>>> marketing more
>>>> appropriate to translates user@ decisions in "how to drive them to
>>>> the
>>>> public"? If you all agree with that, you can move this discussion
>>>> to user@
>>>> or dev@, don't know what is preferable.
>>>>
>>>>
>>>> 2015-05-08 15:56 GMT+02:00 Joan Touzet <wo...@apache.org>:
>>>>
>>>>> Hi all,
>>>>>
>>>>> PMC hat on...
>>>>>
>>>>> Reminding you *again* that we should not be using the MARKETING
>>>>> list to
>>>>> discuss new FEATURES and functionality for Apache CouchDB. We are
>>>>> not
>>>>> like a company where marketing makes up what they want to do, and
>>>>> development is forced to implement it. While it's a good idea to
>>>>> have a
>>>>> feedback loop between marketing and development, I am especially
>>>>> keen to
>>>>> not see Apache CouchDB turn into a marketing-driven development
>>>>> effort.
>>>>>
>>>>> If you are proposing new CouchDB features, please make those
>>>>> proposals
>>>>> on the dev@ mailing list. And if you are willing to *develop* and
>>>>> *support* those functions - even better. Current CouchDB
>>>>> development
>>>>> bandwidth is extremely limited, and would best be served by
>>>>> helping you
>>>>> to understand the current design's constraints, and the
>>>>> difficulties
>>>>> that may be inherent in what you ask for.
>>>>>
>>>>> Best regards,
>>>>> Joan
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Giovanni Lenzi" <g....@smileupps.com>
>>>>>> To: marketing@couchdb.apache.org
>>>>>> Sent: Friday, May 8, 2015 4:05:12 AM
>>>>>> Subject: Re: the future of couchapp
>>>>>>
>>>>>>> A service-trigger feature could be one of the new features of
>>>>>>> Couch
>>>>>>> apps.
>>>>>> if possible, would be awesome :)
>>>>>>
>>>>>>> some clear design goals and a very limited set of features to
>>>>>>> add
>>>>>>> to
>>>>>> CouchDB ddocs and focus on an in-browser tool (add features to
>>>>>> Fauxton)
>>>>>> that removes the need for new developers to learn git and build
>>>>>> tools
>>>>
>>>> --
>>>> Giovanni Lenzi
>>>> www.smileupps.com
>>>> Smileupps Cloud App Store
>>>>
>>>
>>
>> --
>> In theory, there is no difference between theory and practice.
>> In practice, there is.   .... Yogi Berra
>>
>>


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

Re: the future of couchapp

[Johs Ensby <jo...@b2w.com>]

Miles,
I dont disagree much with you, especially not when you say..
> On 12 May 2015, at 16:36, Miles Fidelman <mf...@meetinghouse.net> wrote:
>  they conduct market research to understand your (my) type of customer, they make a decision to serve customers like you (or me), they manage specifications to tailor products to your (my) market segment. 


This pretty much the point I have tried to make in a discussion about whether or not features belong in a discussion about marketing.

Johs

Re: the future of couchapp

[Miles Fidelman <mf...@meetinghouse.net>]

Johs,

Respectfully, you're just wrong.

Considering that I spend my work day doing business development for 
software products (well, systems built around software products) - and 
have done so for about 45 years, in multiple industries and for multiple 
firms (including a couple of my own) - I think I can speak with some 
authority on the subject.

Marketing brings people to your door, or gets you in their door - but 
after that, it's all about sales.  Two very different activities - but 
something that marketeers never seem to understand (salesmen always do).

Marketing remains the way we find prospects, make them aware of our 
existence, spark their interest, open a door.  After that, it's hands on 
sales - building and maintaining relationships, keeping track of 
specific opportunities as they arise, influencing RFPs, writing 
proposals, and so forth.

Sure, the equation has changed a bit for commodity products - with 
marketing leading directly to "click to buy" - but anything that has a 
serious price tag, or a custom component - remains more about sales, 
than marketing.  Marketing may bring the eyeballs to the "add to cart" 
button, but it doesn't get someone to click the button.  You still have 
to induce someone to click "buy" for your product or service, rather 
than moving on to someone else's offer, or not buying anything.  That's 
all sales.

Re. "No one sells me Mac or iPhone, Apple don't bother turning me into a 
lead. They serve my needs and wants. Same thing with AWS."

Of course Apple turns you (and me) into a lead - they conduct market 
research to understand your (my) type of customer, they make a decision 
to serve customers like you (or me), they manage specifications to 
tailor products to your (my) market segment. Then they let people about 
their current products - through advertising, stores, literature (online 
and off), promotion, and so forth -- all designed to make sure that when 
one is ready to buy their next computer, they either walk into an Apple 
Store, or go to Apple's web site (or maybe Best Buy).  That's all lead 
generation.  Inducing someone to take the next step, and plunk down 
$1000+ for a new PowerBook, rather than listen to one of the other 
voices in their head ("maybe I'm ready to switch to a linux desktop," or 
"boy that MicroSoft Surface is a sweet machine") - that's still sales 
(as is helping one decide which model, with which options, and which 
add-ons).

Miles

Johs. E wrote:
> Hi Miles,
> leads gen is another concept in the sales paradigm of the 1960's that is
> very popular in companies that dont't understand the marketing concept.
> Marketing is really about leaving sales behind.
> No one sells me Mac or iPhone, Apple don't bother turning me into a lead.
> They serve my needs and wants. Same thing with AWS.
> Johs:)
>
> 2015-05-12 14:28 GMT+02:00 Miles Fidelman <mf...@meetinghouse.net>:
>
>> I've always preferred the functional view of marketing:  Lead Generation.
>> After getting someone's attention, and getting them to ask for more
>> information, then we're talking sales.
>>
>> Miles Fidelman
>>
>>
>>
>> Johs Ensby wrote:
>>
>>> Jan,
>>>
>>> Hi PMC,
>>> I would like to share my two favourite definitions of marketing.
>>>
>>> 1) the externally oriented:
>>> Create value and extract a fair share of it
>>>
>>> Even if it is the Harvard Business School definition and points at
>>> monetary reward proportionate to the (much bigger) value created for
>>> customers (users), I think it applies. CouchDB developers create value for
>>> users, for which they are rewarded in more than economical ways. Reward is
>>> in the end proportionate to the value created for external parties.
>>>
>>> 2) the internally oriented:
>>> Align resources to meed customer needs
>>>
>>> This is why it is so important to have target groups and distribution
>>> channels in mind. CouchDB has more than one target group, reducing it to
>>> the core developers themselves in a “I do what inspires me” is of course
>>> the extreme, but even reducing the target group to developers with a
>>> specific skill set is a dramatic choice, as is reducing the target group to
>>> developers at large, since they are often not the most influential decision
>>> makers in the selection of technology. When a developer suggests a
>>> technology to a customer or a management team they will be looking at the
>>> challenge of recruiting people as one of their first concerns.
>>>
>>> Imagine the developer who says CouchDB seems like the most promising
>>> NoSql option, and his non-developer peers do this:
>>>
>>> https://www.google.com/trends/explore#q=couchdb%2C%20redis%2C%20mongodb&date=1%2F2009%2073m&cmpt=q&tz=
>>> <https://www.google.com/trends/explore#q=couchdb, redis,
>>> mongodb&date=1/2009 73m&cmpt=q&tz=>
>>>
>>> Wouldn’t it be nice if a million young developers were playing with the
>>> technology in a way that recruited another million and those two millions
>>> recruited another two millions and….
>>>
>>> https://www.google.com/trends/explore#q=couchdb%2C%20couch%20app%2C%20react.js%2C%20angular.js&date=1%2F2009%2073m&cmpt=q&tz=
>>> <https://www.google.com/trends/explore#q=couchdb, couch app, react.js,
>>> angular.js&date=1/2009 73m&cmpt=q&tz=>
>>>
>>> What would it take?
>>> You are spot-on re Couch apps here, Jan :
>>>
>>>> On 11 May 2015, at 18:53, Jan Lehnardt <ja...@apache.org> wrote:
>>>>
>>>> FWIW, I don’t think there’d be massive changes, just some rearrangements
>>>> and some additions and some cuts and mostly story telling on our various
>>>> media outlets.
>>>>
>>> What is stopping us right now, is a misconception of what marketing
>>> actually is.
>>> Marketing is much more than promotion -- like language is much more than
>>> speaking French or writing in C. It is fundamentally about 2-way
>>> communication with the audience you choose.
>>>
>>> I am not looking for a Wozniak/Jobs or Straubel/Musk kind of balance
>>> between the developer and marketing discipline.
>>> Jan, your “can play a role” through “figuring out the story” is more than
>>> enough for me, but I don’t see the point in contributing if the PMC keeps
>>> up the policing against discussions about features.
>>>
>>>   marketing@ can play a role in defining the features of CouchDB through
>>>>> the figuring out the story of CouchDB.
>>>>>
>>> The best part of your take on this is that it is not a one-way street
>>> from communicators to developers or vice versa, which seems to be where the
>>> present misconception is rooted. There needs to be certain portion of
>>> mutual respect between at least those two disciplines for marketing to
>>> happen. Defining features and figuring out the story is an iterative,
>>> dialogue-based process, where starting in one end is not better than
>>> starting in the other.
>>>
>>> Johs
>>>
>>>
>>>
>> --
>> In theory, there is no difference between theory and practice.
>> In practice, there is.   .... Yogi Berra
>>
>>
>


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

Re: the future of couchapp

["Johs. E" <jo...@b2w.com>]

Hi Miles,
leads gen is another concept in the sales paradigm of the 1960's that is
very popular in companies that dont't understand the marketing concept.
Marketing is really about leaving sales behind.
No one sells me Mac or iPhone, Apple don't bother turning me into a lead.
They serve my needs and wants. Same thing with AWS.
Johs:)

2015-05-12 14:28 GMT+02:00 Miles Fidelman <mf...@meetinghouse.net>:

> I've always preferred the functional view of marketing:  Lead Generation.
> After getting someone's attention, and getting them to ask for more
> information, then we're talking sales.
>
> Miles Fidelman
>
>
>
> Johs Ensby wrote:
>
>> Jan,
>>
>> Hi PMC,
>> I would like to share my two favourite definitions of marketing.
>>
>> 1) the externally oriented:
>> Create value and extract a fair share of it
>>
>> Even if it is the Harvard Business School definition and points at
>> monetary reward proportionate to the (much bigger) value created for
>> customers (users), I think it applies. CouchDB developers create value for
>> users, for which they are rewarded in more than economical ways. Reward is
>> in the end proportionate to the value created for external parties.
>>
>> 2) the internally oriented:
>> Align resources to meed customer needs
>>
>> This is why it is so important to have target groups and distribution
>> channels in mind. CouchDB has more than one target group, reducing it to
>> the core developers themselves in a “I do what inspires me” is of course
>> the extreme, but even reducing the target group to developers with a
>> specific skill set is a dramatic choice, as is reducing the target group to
>> developers at large, since they are often not the most influential decision
>> makers in the selection of technology. When a developer suggests a
>> technology to a customer or a management team they will be looking at the
>> challenge of recruiting people as one of their first concerns.
>>
>> Imagine the developer who says CouchDB seems like the most promising
>> NoSql option, and his non-developer peers do this:
>>
>> https://www.google.com/trends/explore#q=couchdb%2C%20redis%2C%20mongodb&date=1%2F2009%2073m&cmpt=q&tz=
>> <https://www.google.com/trends/explore#q=couchdb, redis,
>> mongodb&date=1/2009 73m&cmpt=q&tz=>
>>
>> Wouldn’t it be nice if a million young developers were playing with the
>> technology in a way that recruited another million and those two millions
>> recruited another two millions and….
>>
>> https://www.google.com/trends/explore#q=couchdb%2C%20couch%20app%2C%20react.js%2C%20angular.js&date=1%2F2009%2073m&cmpt=q&tz=
>> <https://www.google.com/trends/explore#q=couchdb, couch app, react.js,
>> angular.js&date=1/2009 73m&cmpt=q&tz=>
>>
>> What would it take?
>> You are spot-on re Couch apps here, Jan :
>>
>>> On 11 May 2015, at 18:53, Jan Lehnardt <ja...@apache.org> wrote:
>>>
>>> FWIW, I don’t think there’d be massive changes, just some rearrangements
>>> and some additions and some cuts and mostly story telling on our various
>>> media outlets.
>>>
>> What is stopping us right now, is a misconception of what marketing
>> actually is.
>> Marketing is much more than promotion -- like language is much more than
>> speaking French or writing in C. It is fundamentally about 2-way
>> communication with the audience you choose.
>>
>> I am not looking for a Wozniak/Jobs or Straubel/Musk kind of balance
>> between the developer and marketing discipline.
>> Jan, your “can play a role” through “figuring out the story” is more than
>> enough for me, but I don’t see the point in contributing if the PMC keeps
>> up the policing against discussions about features.
>>
>>  marketing@ can play a role in defining the features of CouchDB through
>>>> the figuring out the story of CouchDB.
>>>>
>>>
>> The best part of your take on this is that it is not a one-way street
>> from communicators to developers or vice versa, which seems to be where the
>> present misconception is rooted. There needs to be certain portion of
>> mutual respect between at least those two disciplines for marketing to
>> happen. Defining features and figuring out the story is an iterative,
>> dialogue-based process, where starting in one end is not better than
>> starting in the other.
>>
>> Johs
>>
>>
>>
>
> --
> In theory, there is no difference between theory and practice.
> In practice, there is.   .... Yogi Berra
>
>


-- 
--------------------------------
Johs Ensby
Business to Web AS

Office: Kirkegt. 5, N-0153 Oslo
Phone: + 47 22700 007
Mobil: + 47 46 83 79 86
Mail: johs@b2w.com

Re: the future of couchapp

[Miles Fidelman <mf...@meetinghouse.net>]

I've always preferred the functional view of marketing:  Lead Generation.
After getting someone's attention, and getting them to ask for more 
information, then we're talking sales.

Miles Fidelman



Johs Ensby wrote:
> Jan,
>
> Hi PMC,
> I would like to share my two favourite definitions of marketing.
>
> 1) the externally oriented:
> Create value and extract a fair share of it
>
> Even if it is the Harvard Business School definition and points at monetary reward proportionate to the (much bigger) value created for customers (users), I think it applies. CouchDB developers create value for users, for which they are rewarded in more than economical ways. Reward is in the end proportionate to the value created for external parties.
>
> 2) the internally oriented:
> Align resources to meed customer needs
>
> This is why it is so important to have target groups and distribution channels in mind. CouchDB has more than one target group, reducing it to the core developers themselves in a “I do what inspires me” is of course the extreme, but even reducing the target group to developers with a specific skill set is a dramatic choice, as is reducing the target group to developers at large, since they are often not the most influential decision makers in the selection of technology. When a developer suggests a technology to a customer or a management team they will be looking at the challenge of recruiting people as one of their first concerns.
>
> Imagine the developer who says CouchDB seems like the most promising NoSql option, and his non-developer peers do this:
> https://www.google.com/trends/explore#q=couchdb%2C%20redis%2C%20mongodb&date=1%2F2009%2073m&cmpt=q&tz= <https://www.google.com/trends/explore#q=couchdb, redis, mongodb&date=1/2009 73m&cmpt=q&tz=>
>
> Wouldn’t it be nice if a million young developers were playing with the technology in a way that recruited another million and those two millions recruited another two millions and….
> https://www.google.com/trends/explore#q=couchdb%2C%20couch%20app%2C%20react.js%2C%20angular.js&date=1%2F2009%2073m&cmpt=q&tz= <https://www.google.com/trends/explore#q=couchdb, couch app, react.js, angular.js&date=1/2009 73m&cmpt=q&tz=>
>
> What would it take?
> You are spot-on re Couch apps here, Jan :
>> On 11 May 2015, at 18:53, Jan Lehnardt <ja...@apache.org> wrote:
>>
>> FWIW, I don’t think there’d be massive changes, just some rearrangements and some additions and some cuts and mostly story telling on our various media outlets.
> What is stopping us right now, is a misconception of what marketing actually is.
> Marketing is much more than promotion -- like language is much more than speaking French or writing in C. It is fundamentally about 2-way communication with the audience you choose.
>
> I am not looking for a Wozniak/Jobs or Straubel/Musk kind of balance between the developer and marketing discipline.
> Jan, your “can play a role” through “figuring out the story” is more than enough for me, but I don’t see the point in contributing if the PMC keeps up the policing against discussions about features.
>
>>> marketing@ can play a role in defining the features of CouchDB through
>>> the figuring out the story of CouchDB.
>
> The best part of your take on this is that it is not a one-way street from communicators to developers or vice versa, which seems to be where the present misconception is rooted. There needs to be certain portion of mutual respect between at least those two disciplines for marketing to happen. Defining features and figuring out the story is an iterative, dialogue-based process, where starting in one end is not better than starting in the other.
>
> Johs
>
>


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

Re: the future of couchapp

[Johs Ensby <jo...@b2w.com>]

Jan,

Hi PMC,
I would like to share my two favourite definitions of marketing.

1) the externally oriented:
Create value and extract a fair share of it

Even if it is the Harvard Business School definition and points at monetary reward proportionate to the (much bigger) value created for customers (users), I think it applies. CouchDB developers create value for users, for which they are rewarded in more than economical ways. Reward is in the end proportionate to the value created for external parties.

2) the internally oriented:
Align resources to meed customer needs

This is why it is so important to have target groups and distribution channels in mind. CouchDB has more than one target group, reducing it to the core developers themselves in a “I do what inspires me” is of course the extreme, but even reducing the target group to developers with a specific skill set is a dramatic choice, as is reducing the target group to developers at large, since they are often not the most influential decision makers in the selection of technology. When a developer suggests a technology to a customer or a management team they will be looking at the challenge of recruiting people as one of their first concerns.

Imagine the developer who says CouchDB seems like the most promising NoSql option, and his non-developer peers do this:
https://www.google.com/trends/explore#q=couchdb%2C%20redis%2C%20mongodb&date=1%2F2009%2073m&cmpt=q&tz= <https://www.google.com/trends/explore#q=couchdb, redis, mongodb&date=1/2009 73m&cmpt=q&tz=>

Wouldn’t it be nice if a million young developers were playing with the technology in a way that recruited another million and those two millions recruited another two millions and….
https://www.google.com/trends/explore#q=couchdb%2C%20couch%20app%2C%20react.js%2C%20angular.js&date=1%2F2009%2073m&cmpt=q&tz= <https://www.google.com/trends/explore#q=couchdb, couch app, react.js, angular.js&date=1/2009 73m&cmpt=q&tz=>

What would it take?
You are spot-on re Couch apps here, Jan :
> 
> On 11 May 2015, at 18:53, Jan Lehnardt <ja...@apache.org> wrote:
> 
> FWIW, I don’t think there’d be massive changes, just some rearrangements and some additions and some cuts and mostly story telling on our various media outlets.

What is stopping us right now, is a misconception of what marketing actually is. 
Marketing is much more than promotion -- like language is much more than speaking French or writing in C. It is fundamentally about 2-way communication with the audience you choose.

I am not looking for a Wozniak/Jobs or Straubel/Musk kind of balance between the developer and marketing discipline. 
Jan, your “can play a role” through “figuring out the story” is more than enough for me, but I don’t see the point in contributing if the PMC keeps up the policing against discussions about features.

>> marketing@ can play a role in defining the features of CouchDB through
>> the figuring out the story of CouchDB.


The best part of your take on this is that it is not a one-way street from communicators to developers or vice versa, which seems to be where the present misconception is rooted. There needs to be certain portion of mutual respect between at least those two disciplines for marketing to happen. Defining features and figuring out the story is an iterative, dialogue-based process, where starting in one end is not better than starting in the other.

Johs

Re: the future of couchapp

[Andy Wenk <an...@apache.org>]

Alex, thanks a lot for sharing your thoughts on the topic. I like it a lot
and fully ACK.

Jan, I agree with you but at the end I don't see the need for any
rearrangements or additions or cuts. For me, it was always clear what the
purpose of the marketing list is and you / we already clarified this
various times in this and the regarding threads. Imho, we just need to
communicate this very clearly and with this thread I think it is clear. We
could also add  some clarifications to the description for the marketing ML
on the website if we see a need for it.

All the best

Andy

On 11 May 2015 at 18:53, Jan Lehnardt <ja...@apache.org> wrote:

> I agree that CouchDB is not a
> marketing-decides/sales-sells/engineers-build operation, but I think
> marketing@ can play a role in defining the features of CouchDB through
> the figuring out the story of CouchDB. I realise that I might be unique in
> my position here because my suggestions for marketing@ are implying “I’m
> prepared to do the legwork on dev@” which isn’t true for everyone else
> here, so I need to keep that in mind a little better. I also agree that we
> on marketing@ can’t just dream up something and then hope dev@ builds it,
> but we can help shape the thinking of dev@ once we have some clearer idea
> of what that story can be.
>
> FWIW, I don’t think there’d be massive changes, just some rearrangements
> and some additions and some cuts and mostly story telling on our various
> media outlets.
>
> Best
> Jan
> --
>
>
>
> > On 11 May 2015, at 07:45, Johs Ensby <jo...@b2w.com> wrote:
> >
> > Joan and Andy,
> > “Spreading the word” isn’t marketing.
> > You should rename the list to promotion@ if you think it is.
> > I don’t know where the idea that developers are forced to implement
> suggestions from the marketing list came from, not from me.
> > To discuss marketing without ideas on customer value and future features
> is turning the clock 75 year back.
> > I you are so scared of non-erlang programmer discussing features, why do
> you have a marketing list?
> >
> > Johs
> >
> >> On 09 May 2015, at 21:45, Andy Wenk <an...@apache.org> wrote:
> >>
> >> Joan, thanks a lot for your reminder. This is very well received and I
> >> think the majority of people of this thread do understand, that the
> Apache
> >> CouchDB project is definitely not comparable to "business".
> >>
> >> The goal of the marketing list is more than often defined. This list is
> for
> >> spreading the word about CouchDB like with information in the wiki, logo
> >> stuff, the story of CouchDB, weekly news and so on. As in every Apache
> >> project, the dev@ mailing-list is THE place to discuss any features for
> >> Apache CouchDB.
> >>
> >> One word to CouchApps. I am very happy about the discussion about
> >> CouchApps. And I am strongly supporting everyone who is building stuff
> with
> >> it. Like smileupps is doing. CouchApps have their historical place in
> >> Apache CouchDB. But the way we will support CouchApps further - be it
> the
> >> naming or sth else - is a completely different story.
> >>
> >> So let's separate the topics to the appropriate ML and keep on moving.
> >>
> >> All the best
> >>
> >> Andy
> >>
> >> On 9 May 2015 at 21:25, Joan Touzet <wo...@apache.org> wrote:
> >>
> >>> One additional data point here. I mention "serious customers" as
> >>> narrowly defined in this email as the thousands-to-millions of $
> >>> customers. CouchApps probably have a place in the lower end of the
> >>> market, i.e. shared instance users who have lightweight needs for
> >>> their applications and are customers of IrisCouch or SmileApps. I
> >>> wasn't trying to say there isn't a market for this :) The business
> >>> case to be made for them is very different, i.e. razor thin margins
> >>> across thousands to millions of people. Such an approach wasn't
> >>> logical for Cloudant - the shared instances don't drive the company
> >>> like the dedicated instances do. Because of this data I think
> >>> CouchApps as a primary user story is very hard road to walk for us.
> >>>
> >>> ----- Original Message -----
> >>>> From: "Joan Touzet" <wo...@apache.org>
> >>>> To: marketing@couchdb.apache.org
> >>>> Cc: "Mike Broberg" <mb...@us.ibm.com>, smetson@uk.ibm.com
> >>>> Sent: Saturday, May 9, 2015 2:26:26 PM
> >>>> Subject: Re: the future of couchapp
> >>>>
> >>>> Hi Miles,
> >>>>
> >>>> DISCLAIMER: I am not speaking as an official representative of IBM or
> >>>> Cloudant. I have cc'ed Mike Broberg, who can speak for them if
> >>>> necessary. (I also want him to be aware of what I am saying here).
> >>>>
> >>>> *** TL;DR: the people who are willing to spend anywhere from
> >>>> thousands to millions of dollars on a CouchDB-based solution aren't
> >>>> interested in CouchApps. I think the discussion to date is missing
> >>>> this, and as such, is entirely unrepresentative of the current
> >>>> market for Apache CouchDB.
> >>>>
> >>>> The answer is that there are practically no customers of Cloudant/IBM
> >>>> who are banking on CouchApps for any serious need. Every client that
> >>>> I can think of - meaning they have a dedicated cluster, and aren't
> >>>> using the shared cluster service - are using either a traditional
> >>>> three-tier app server structure (Node.JS, Python, PHP, Ruby, Java,
> >>>> .NET, etc.) or are doing client-side development on mobile platforms
> >>>> (iOS + TouchDB, Android + PouchDB) where they are replicating back to
> >>>> the Cloudant clusters for data exchange. In all of these scenarios,
> >>>> replication is the "killer feature" for CouchDB, with the REST
> >>>> interface a close second, and the ease of unstructured JSON data as
> >>>> a third.
> >>>>
> >>>> Cloudant built out a document-level (and field-level!) security
> >>>> solution for one customer, about two years ago now. While there was
> >>>> initial interest, performance considerations lead to the solution
> >>>> being backburnered for further consideration. Even in that situation,
> >>>> CouchApps weren't the primary concern -- database-level enforcement
> >>>> of security rules *was*.
> >>>>
> >>>> Within Cloudant, perhaps Simon Metson was the primary proponent of
> >>>> using CouchApps for serious purposes. He used them in the "For
> >>>> Developers" section of the website to help demonstrate various key
> >>>> features of the platform, including the new MongoDB-inspired Mango
> >>>> feature that's now a part of CouchDB 2.0. Diana Thayer (@garbados)
> >>>> picked up on this and built a documentation framework on top of
> >>>> CouchApps. This, to me, is perhaps the ideal use of CouchApps:
> >>>> unsecured content, read-only, displayed in different formats based
> >>>> upon what the end user needs, and self-hosted by CouchDB (so you
> >>>> can view the product's documentation using the product itself).
> >>>> More information on this use is at:
> >>>>
> >>>>
> >>>
> https://mail-archives.apache.org/mod_mbox/couchdb-dev/201410.mbox/%3C28603443.66.1414446738764.JavaMail.joant@Joans-MacBook-Pro.local%3E
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Miles Fidelman" <mf...@meetinghouse.net>
> >>>>> To: marketing@couchdb.apache.org
> >>>>> Sent: Friday, May 8, 2015 11:21:28 AM
> >>>>> Subject: Re: the future of couchapp
> >>>>>
> >>>>> Let's be clear.
> >>>>> (Good) marketing isn't about selling a solution to folks who don't
> >>>>> have
> >>>>> a problem in the first place, it's about it's identifying problems
> >>>>> for
> >>>>> which we offer a solution.
> >>>>>
> >>>>> And.. it occurs to me that Cloudant has been doing market research
> >>>>> and
> >>>>> "real" marketing - perhaps some folks from Cloudant might share
> >>>>> some
> >>>>> findings related to CouchDB (as opposed to those that might relate
> >>>>> to
> >>>>> their commercial extensions and services)?
> >>>>>
> >>>>> Miles Fidelman
> >>>>>
> >>>>>
> >>>>>
> >>>>> Giovanni Lenzi wrote:
> >>>>>>> translates user@ decisions in "how to drive them to the public"?
> >>>>>> or maybe better how to drive dev@ implemented features to the
> >>>>>> public ?
> >>>>>>
> >>>>>> 2015-05-08 16:57 GMT+02:00 Giovanni Lenzi
> >>>>>> <g....@smileupps.com>:
> >>>>>>
> >>>>>>> Got it, Joan. Thanks for the useful reminder, considered I am a
> >>>>>>> total
> >>>>>>> newbie here, I definitely don't know how decision-making process
> >>>>>>> is driven.
> >>>>>>>
> >>>>>>> We will cut the "features" part from this discussion then and
> >>>>>>> take
> >>>>>>> it to
> >>>>>>> the devs@ list
> >>>>>>>
> >>>>>>> Here we should then focus on @jan's request about the story for
> >>>>>>> couchapps.. given that until 2 days ago that was somehow
> >>>>>>> uncertain
> >>>>>>>
> >>>>>>> But I think too this is more a user@ topic... isn't maybe
> >>>>>>> marketing more
> >>>>>>> appropriate to translates user@ decisions in "how to drive them
> >>>>>>> to
> >>>>>>> the
> >>>>>>> public"? If you all agree with that, you can move this
> >>>>>>> discussion
> >>>>>>> to user@
> >>>>>>> or dev@, don't know what is preferable.
> >>>>>>>
> >>>>>>>
> >>>>>>> 2015-05-08 15:56 GMT+02:00 Joan Touzet <wo...@apache.org>:
> >>>>>>>
> >>>>>>>> Hi all,
> >>>>>>>>
> >>>>>>>> PMC hat on...
> >>>>>>>>
> >>>>>>>> Reminding you *again* that we should not be using the MARKETING
> >>>>>>>> list to
> >>>>>>>> discuss new FEATURES and functionality for Apache CouchDB. We
> >>>>>>>> are
> >>>>>>>> not
> >>>>>>>> like a company where marketing makes up what they want to do,
> >>>>>>>> and
> >>>>>>>> development is forced to implement it. While it's a good idea
> >>>>>>>> to
> >>>>>>>> have a
> >>>>>>>> feedback loop between marketing and development, I am
> >>>>>>>> especially
> >>>>>>>> keen to
> >>>>>>>> not see Apache CouchDB turn into a marketing-driven development
> >>>>>>>> effort.
> >>>>>>>>
> >>>>>>>> If you are proposing new CouchDB features, please make those
> >>>>>>>> proposals
> >>>>>>>> on the dev@ mailing list. And if you are willing to *develop*
> >>>>>>>> and
> >>>>>>>> *support* those functions - even better. Current CouchDB
> >>>>>>>> development
> >>>>>>>> bandwidth is extremely limited, and would best be served by
> >>>>>>>> helping you
> >>>>>>>> to understand the current design's constraints, and the
> >>>>>>>> difficulties
> >>>>>>>> that may be inherent in what you ask for.
> >>>>>>>>
> >>>>>>>> Best regards,
> >>>>>>>> Joan
> >>>>>>>>
> >>>>>>>> ----- Original Message -----
> >>>>>>>>> From: "Giovanni Lenzi" <g....@smileupps.com>
> >>>>>>>>> To: marketing@couchdb.apache.org
> >>>>>>>>> Sent: Friday, May 8, 2015 4:05:12 AM
> >>>>>>>>> Subject: Re: the future of couchapp
> >>>>>>>>>
> >>>>>>>>>> A service-trigger feature could be one of the new features of
> >>>>>>>>>> Couch
> >>>>>>>>>> apps.
> >>>>>>>>> if possible, would be awesome :)
> >>>>>>>>>
> >>>>>>>>>> some clear design goals and a very limited set of features to
> >>>>>>>>>> add
> >>>>>>>>>> to
> >>>>>>>>> CouchDB ddocs and focus on an in-browser tool (add features to
> >>>>>>>>> Fauxton)
> >>>>>>>>> that removes the need for new developers to learn git and
> >>>>>>>>> build
> >>>>>>>>> tools
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Giovanni Lenzi
> >>>>>>> www.smileupps.com
> >>>>>>> Smileupps Cloud App Store
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> In theory, there is no difference between theory and practice.
> >>>>> In practice, there is.   .... Yogi Berra
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> >>
> >>
> >> --
> >> 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

Re: the future of couchapp

[Jan Lehnardt <ja...@apache.org>]

I agree that CouchDB is not a marketing-decides/sales-sells/engineers-build operation, but I think marketing@ can play a role in defining the features of CouchDB through the figuring out the story of CouchDB. I realise that I might be unique in my position here because my suggestions for marketing@ are implying “I’m prepared to do the legwork on dev@” which isn’t true for everyone else here, so I need to keep that in mind a little better. I also agree that we on marketing@ can’t just dream up something and then hope dev@ builds it, but we can help shape the thinking of dev@ once we have some clearer idea of what that story can be.

FWIW, I don’t think there’d be massive changes, just some rearrangements and some additions and some cuts and mostly story telling on our various media outlets.

Best
Jan
--



> On 11 May 2015, at 07:45, Johs Ensby <jo...@b2w.com> wrote:
> 
> Joan and Andy,
> “Spreading the word” isn’t marketing.
> You should rename the list to promotion@ if you think it is.
> I don’t know where the idea that developers are forced to implement suggestions from the marketing list came from, not from me.
> To discuss marketing without ideas on customer value and future features is turning the clock 75 year back.
> I you are so scared of non-erlang programmer discussing features, why do you have a marketing list?
> 
> Johs
> 
>> On 09 May 2015, at 21:45, Andy Wenk <an...@apache.org> wrote:
>> 
>> Joan, thanks a lot for your reminder. This is very well received and I
>> think the majority of people of this thread do understand, that the Apache
>> CouchDB project is definitely not comparable to "business".
>> 
>> The goal of the marketing list is more than often defined. This list is for
>> spreading the word about CouchDB like with information in the wiki, logo
>> stuff, the story of CouchDB, weekly news and so on. As in every Apache
>> project, the dev@ mailing-list is THE place to discuss any features for
>> Apache CouchDB.
>> 
>> One word to CouchApps. I am very happy about the discussion about
>> CouchApps. And I am strongly supporting everyone who is building stuff with
>> it. Like smileupps is doing. CouchApps have their historical place in
>> Apache CouchDB. But the way we will support CouchApps further - be it the
>> naming or sth else - is a completely different story.
>> 
>> So let's separate the topics to the appropriate ML and keep on moving.
>> 
>> All the best
>> 
>> Andy
>> 
>> On 9 May 2015 at 21:25, Joan Touzet <wo...@apache.org> wrote:
>> 
>>> One additional data point here. I mention "serious customers" as
>>> narrowly defined in this email as the thousands-to-millions of $
>>> customers. CouchApps probably have a place in the lower end of the
>>> market, i.e. shared instance users who have lightweight needs for
>>> their applications and are customers of IrisCouch or SmileApps. I
>>> wasn't trying to say there isn't a market for this :) The business
>>> case to be made for them is very different, i.e. razor thin margins
>>> across thousands to millions of people. Such an approach wasn't
>>> logical for Cloudant - the shared instances don't drive the company
>>> like the dedicated instances do. Because of this data I think
>>> CouchApps as a primary user story is very hard road to walk for us.
>>> 
>>> ----- Original Message -----
>>>> From: "Joan Touzet" <wo...@apache.org>
>>>> To: marketing@couchdb.apache.org
>>>> Cc: "Mike Broberg" <mb...@us.ibm.com>, smetson@uk.ibm.com
>>>> Sent: Saturday, May 9, 2015 2:26:26 PM
>>>> Subject: Re: the future of couchapp
>>>> 
>>>> Hi Miles,
>>>> 
>>>> DISCLAIMER: I am not speaking as an official representative of IBM or
>>>> Cloudant. I have cc'ed Mike Broberg, who can speak for them if
>>>> necessary. (I also want him to be aware of what I am saying here).
>>>> 
>>>> *** TL;DR: the people who are willing to spend anywhere from
>>>> thousands to millions of dollars on a CouchDB-based solution aren't
>>>> interested in CouchApps. I think the discussion to date is missing
>>>> this, and as such, is entirely unrepresentative of the current
>>>> market for Apache CouchDB.
>>>> 
>>>> The answer is that there are practically no customers of Cloudant/IBM
>>>> who are banking on CouchApps for any serious need. Every client that
>>>> I can think of - meaning they have a dedicated cluster, and aren't
>>>> using the shared cluster service - are using either a traditional
>>>> three-tier app server structure (Node.JS, Python, PHP, Ruby, Java,
>>>> .NET, etc.) or are doing client-side development on mobile platforms
>>>> (iOS + TouchDB, Android + PouchDB) where they are replicating back to
>>>> the Cloudant clusters for data exchange. In all of these scenarios,
>>>> replication is the "killer feature" for CouchDB, with the REST
>>>> interface a close second, and the ease of unstructured JSON data as
>>>> a third.
>>>> 
>>>> Cloudant built out a document-level (and field-level!) security
>>>> solution for one customer, about two years ago now. While there was
>>>> initial interest, performance considerations lead to the solution
>>>> being backburnered for further consideration. Even in that situation,
>>>> CouchApps weren't the primary concern -- database-level enforcement
>>>> of security rules *was*.
>>>> 
>>>> Within Cloudant, perhaps Simon Metson was the primary proponent of
>>>> using CouchApps for serious purposes. He used them in the "For
>>>> Developers" section of the website to help demonstrate various key
>>>> features of the platform, including the new MongoDB-inspired Mango
>>>> feature that's now a part of CouchDB 2.0. Diana Thayer (@garbados)
>>>> picked up on this and built a documentation framework on top of
>>>> CouchApps. This, to me, is perhaps the ideal use of CouchApps:
>>>> unsecured content, read-only, displayed in different formats based
>>>> upon what the end user needs, and self-hosted by CouchDB (so you
>>>> can view the product's documentation using the product itself).
>>>> More information on this use is at:
>>>> 
>>>> 
>>> https://mail-archives.apache.org/mod_mbox/couchdb-dev/201410.mbox/%3C28603443.66.1414446738764.JavaMail.joant@Joans-MacBook-Pro.local%3E
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> ----- Original Message -----
>>>>> From: "Miles Fidelman" <mf...@meetinghouse.net>
>>>>> To: marketing@couchdb.apache.org
>>>>> Sent: Friday, May 8, 2015 11:21:28 AM
>>>>> Subject: Re: the future of couchapp
>>>>> 
>>>>> Let's be clear.
>>>>> (Good) marketing isn't about selling a solution to folks who don't
>>>>> have
>>>>> a problem in the first place, it's about it's identifying problems
>>>>> for
>>>>> which we offer a solution.
>>>>> 
>>>>> And.. it occurs to me that Cloudant has been doing market research
>>>>> and
>>>>> "real" marketing - perhaps some folks from Cloudant might share
>>>>> some
>>>>> findings related to CouchDB (as opposed to those that might relate
>>>>> to
>>>>> their commercial extensions and services)?
>>>>> 
>>>>> Miles Fidelman
>>>>> 
>>>>> 
>>>>> 
>>>>> Giovanni Lenzi wrote:
>>>>>>> translates user@ decisions in "how to drive them to the public"?
>>>>>> or maybe better how to drive dev@ implemented features to the
>>>>>> public ?
>>>>>> 
>>>>>> 2015-05-08 16:57 GMT+02:00 Giovanni Lenzi
>>>>>> <g....@smileupps.com>:
>>>>>> 
>>>>>>> Got it, Joan. Thanks for the useful reminder, considered I am a
>>>>>>> total
>>>>>>> newbie here, I definitely don't know how decision-making process
>>>>>>> is driven.
>>>>>>> 
>>>>>>> We will cut the "features" part from this discussion then and
>>>>>>> take
>>>>>>> it to
>>>>>>> the devs@ list
>>>>>>> 
>>>>>>> Here we should then focus on @jan's request about the story for
>>>>>>> couchapps.. given that until 2 days ago that was somehow
>>>>>>> uncertain
>>>>>>> 
>>>>>>> But I think too this is more a user@ topic... isn't maybe
>>>>>>> marketing more
>>>>>>> appropriate to translates user@ decisions in "how to drive them
>>>>>>> to
>>>>>>> the
>>>>>>> public"? If you all agree with that, you can move this
>>>>>>> discussion
>>>>>>> to user@
>>>>>>> or dev@, don't know what is preferable.
>>>>>>> 
>>>>>>> 
>>>>>>> 2015-05-08 15:56 GMT+02:00 Joan Touzet <wo...@apache.org>:
>>>>>>> 
>>>>>>>> Hi all,
>>>>>>>> 
>>>>>>>> PMC hat on...
>>>>>>>> 
>>>>>>>> Reminding you *again* that we should not be using the MARKETING
>>>>>>>> list to
>>>>>>>> discuss new FEATURES and functionality for Apache CouchDB. We
>>>>>>>> are
>>>>>>>> not
>>>>>>>> like a company where marketing makes up what they want to do,
>>>>>>>> and
>>>>>>>> development is forced to implement it. While it's a good idea
>>>>>>>> to
>>>>>>>> have a
>>>>>>>> feedback loop between marketing and development, I am
>>>>>>>> especially
>>>>>>>> keen to
>>>>>>>> not see Apache CouchDB turn into a marketing-driven development
>>>>>>>> effort.
>>>>>>>> 
>>>>>>>> If you are proposing new CouchDB features, please make those
>>>>>>>> proposals
>>>>>>>> on the dev@ mailing list. And if you are willing to *develop*
>>>>>>>> and
>>>>>>>> *support* those functions - even better. Current CouchDB
>>>>>>>> development
>>>>>>>> bandwidth is extremely limited, and would best be served by
>>>>>>>> helping you
>>>>>>>> to understand the current design's constraints, and the
>>>>>>>> difficulties
>>>>>>>> that may be inherent in what you ask for.
>>>>>>>> 
>>>>>>>> Best regards,
>>>>>>>> Joan
>>>>>>>> 
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Giovanni Lenzi" <g....@smileupps.com>
>>>>>>>>> To: marketing@couchdb.apache.org
>>>>>>>>> Sent: Friday, May 8, 2015 4:05:12 AM
>>>>>>>>> Subject: Re: the future of couchapp
>>>>>>>>> 
>>>>>>>>>> A service-trigger feature could be one of the new features of
>>>>>>>>>> Couch
>>>>>>>>>> apps.
>>>>>>>>> if possible, would be awesome :)
>>>>>>>>> 
>>>>>>>>>> some clear design goals and a very limited set of features to
>>>>>>>>>> add
>>>>>>>>>> to
>>>>>>>>> CouchDB ddocs and focus on an in-browser tool (add features to
>>>>>>>>> Fauxton)
>>>>>>>>> that removes the need for new developers to learn git and
>>>>>>>>> build
>>>>>>>>> tools
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Giovanni Lenzi
>>>>>>> www.smileupps.com
>>>>>>> Smileupps Cloud App Store
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> In theory, there is no difference between theory and practice.
>>>>> In practice, there is.   .... Yogi Berra
>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>> 
>> 
>> -- 
>> 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/

Re: the future of couchapp

[Johs Ensby <jo...@b2w.com>]

Joan and Andy,
“Spreading the word” isn’t marketing.
You should rename the list to promotion@ if you think it is.
I don’t know where the idea that developers are forced to implement suggestions from the marketing list came from, not from me.
To discuss marketing without ideas on customer value and future features is turning the clock 75 year back.
I you are so scared of non-erlang programmer discussing features, why do you have a marketing list?

Johs

> On 09 May 2015, at 21:45, Andy Wenk <an...@apache.org> wrote:
> 
> Joan, thanks a lot for your reminder. This is very well received and I
> think the majority of people of this thread do understand, that the Apache
> CouchDB project is definitely not comparable to "business".
> 
> The goal of the marketing list is more than often defined. This list is for
> spreading the word about CouchDB like with information in the wiki, logo
> stuff, the story of CouchDB, weekly news and so on. As in every Apache
> project, the dev@ mailing-list is THE place to discuss any features for
> Apache CouchDB.
> 
> One word to CouchApps. I am very happy about the discussion about
> CouchApps. And I am strongly supporting everyone who is building stuff with
> it. Like smileupps is doing. CouchApps have their historical place in
> Apache CouchDB. But the way we will support CouchApps further - be it the
> naming or sth else - is a completely different story.
> 
> So let's separate the topics to the appropriate ML and keep on moving.
> 
> All the best
> 
> Andy
> 
> On 9 May 2015 at 21:25, Joan Touzet <wo...@apache.org> wrote:
> 
>> One additional data point here. I mention "serious customers" as
>> narrowly defined in this email as the thousands-to-millions of $
>> customers. CouchApps probably have a place in the lower end of the
>> market, i.e. shared instance users who have lightweight needs for
>> their applications and are customers of IrisCouch or SmileApps. I
>> wasn't trying to say there isn't a market for this :) The business
>> case to be made for them is very different, i.e. razor thin margins
>> across thousands to millions of people. Such an approach wasn't
>> logical for Cloudant - the shared instances don't drive the company
>> like the dedicated instances do. Because of this data I think
>> CouchApps as a primary user story is very hard road to walk for us.
>> 
>> ----- Original Message -----
>>> From: "Joan Touzet" <wo...@apache.org>
>>> To: marketing@couchdb.apache.org
>>> Cc: "Mike Broberg" <mb...@us.ibm.com>, smetson@uk.ibm.com
>>> Sent: Saturday, May 9, 2015 2:26:26 PM
>>> Subject: Re: the future of couchapp
>>> 
>>> Hi Miles,
>>> 
>>> DISCLAIMER: I am not speaking as an official representative of IBM or
>>> Cloudant. I have cc'ed Mike Broberg, who can speak for them if
>>> necessary. (I also want him to be aware of what I am saying here).
>>> 
>>> *** TL;DR: the people who are willing to spend anywhere from
>>> thousands to millions of dollars on a CouchDB-based solution aren't
>>> interested in CouchApps. I think the discussion to date is missing
>>> this, and as such, is entirely unrepresentative of the current
>>> market for Apache CouchDB.
>>> 
>>> The answer is that there are practically no customers of Cloudant/IBM
>>> who are banking on CouchApps for any serious need. Every client that
>>> I can think of - meaning they have a dedicated cluster, and aren't
>>> using the shared cluster service - are using either a traditional
>>> three-tier app server structure (Node.JS, Python, PHP, Ruby, Java,
>>> .NET, etc.) or are doing client-side development on mobile platforms
>>> (iOS + TouchDB, Android + PouchDB) where they are replicating back to
>>> the Cloudant clusters for data exchange. In all of these scenarios,
>>> replication is the "killer feature" for CouchDB, with the REST
>>> interface a close second, and the ease of unstructured JSON data as
>>> a third.
>>> 
>>> Cloudant built out a document-level (and field-level!) security
>>> solution for one customer, about two years ago now. While there was
>>> initial interest, performance considerations lead to the solution
>>> being backburnered for further consideration. Even in that situation,
>>> CouchApps weren't the primary concern -- database-level enforcement
>>> of security rules *was*.
>>> 
>>> Within Cloudant, perhaps Simon Metson was the primary proponent of
>>> using CouchApps for serious purposes. He used them in the "For
>>> Developers" section of the website to help demonstrate various key
>>> features of the platform, including the new MongoDB-inspired Mango
>>> feature that's now a part of CouchDB 2.0. Diana Thayer (@garbados)
>>> picked up on this and built a documentation framework on top of
>>> CouchApps. This, to me, is perhaps the ideal use of CouchApps:
>>> unsecured content, read-only, displayed in different formats based
>>> upon what the end user needs, and self-hosted by CouchDB (so you
>>> can view the product's documentation using the product itself).
>>> More information on this use is at:
>>> 
>>> 
>> https://mail-archives.apache.org/mod_mbox/couchdb-dev/201410.mbox/%3C28603443.66.1414446738764.JavaMail.joant@Joans-MacBook-Pro.local%3E
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ----- Original Message -----
>>>> From: "Miles Fidelman" <mf...@meetinghouse.net>
>>>> To: marketing@couchdb.apache.org
>>>> Sent: Friday, May 8, 2015 11:21:28 AM
>>>> Subject: Re: the future of couchapp
>>>> 
>>>> Let's be clear.
>>>> (Good) marketing isn't about selling a solution to folks who don't
>>>> have
>>>> a problem in the first place, it's about it's identifying problems
>>>> for
>>>> which we offer a solution.
>>>> 
>>>> And.. it occurs to me that Cloudant has been doing market research
>>>> and
>>>> "real" marketing - perhaps some folks from Cloudant might share
>>>> some
>>>> findings related to CouchDB (as opposed to those that might relate
>>>> to
>>>> their commercial extensions and services)?
>>>> 
>>>> Miles Fidelman
>>>> 
>>>> 
>>>> 
>>>> Giovanni Lenzi wrote:
>>>>>> translates user@ decisions in "how to drive them to the public"?
>>>>> or maybe better how to drive dev@ implemented features to the
>>>>> public ?
>>>>> 
>>>>> 2015-05-08 16:57 GMT+02:00 Giovanni Lenzi
>>>>> <g....@smileupps.com>:
>>>>> 
>>>>>> Got it, Joan. Thanks for the useful reminder, considered I am a
>>>>>> total
>>>>>> newbie here, I definitely don't know how decision-making process
>>>>>> is driven.
>>>>>> 
>>>>>> We will cut the "features" part from this discussion then and
>>>>>> take
>>>>>> it to
>>>>>> the devs@ list
>>>>>> 
>>>>>> Here we should then focus on @jan's request about the story for
>>>>>> couchapps.. given that until 2 days ago that was somehow
>>>>>> uncertain
>>>>>> 
>>>>>> But I think too this is more a user@ topic... isn't maybe
>>>>>> marketing more
>>>>>> appropriate to translates user@ decisions in "how to drive them
>>>>>> to
>>>>>> the
>>>>>> public"? If you all agree with that, you can move this
>>>>>> discussion
>>>>>> to user@
>>>>>> or dev@, don't know what is preferable.
>>>>>> 
>>>>>> 
>>>>>> 2015-05-08 15:56 GMT+02:00 Joan Touzet <wo...@apache.org>:
>>>>>> 
>>>>>>> Hi all,
>>>>>>> 
>>>>>>> PMC hat on...
>>>>>>> 
>>>>>>> Reminding you *again* that we should not be using the MARKETING
>>>>>>> list to
>>>>>>> discuss new FEATURES and functionality for Apache CouchDB. We
>>>>>>> are
>>>>>>> not
>>>>>>> like a company where marketing makes up what they want to do,
>>>>>>> and
>>>>>>> development is forced to implement it. While it's a good idea
>>>>>>> to
>>>>>>> have a
>>>>>>> feedback loop between marketing and development, I am
>>>>>>> especially
>>>>>>> keen to
>>>>>>> not see Apache CouchDB turn into a marketing-driven development
>>>>>>> effort.
>>>>>>> 
>>>>>>> If you are proposing new CouchDB features, please make those
>>>>>>> proposals
>>>>>>> on the dev@ mailing list. And if you are willing to *develop*
>>>>>>> and
>>>>>>> *support* those functions - even better. Current CouchDB
>>>>>>> development
>>>>>>> bandwidth is extremely limited, and would best be served by
>>>>>>> helping you
>>>>>>> to understand the current design's constraints, and the
>>>>>>> difficulties
>>>>>>> that may be inherent in what you ask for.
>>>>>>> 
>>>>>>> Best regards,
>>>>>>> Joan
>>>>>>> 
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Giovanni Lenzi" <g....@smileupps.com>
>>>>>>>> To: marketing@couchdb.apache.org
>>>>>>>> Sent: Friday, May 8, 2015 4:05:12 AM
>>>>>>>> Subject: Re: the future of couchapp
>>>>>>>> 
>>>>>>>>> A service-trigger feature could be one of the new features of
>>>>>>>>> Couch
>>>>>>>>> apps.
>>>>>>>> if possible, would be awesome :)
>>>>>>>> 
>>>>>>>>> some clear design goals and a very limited set of features to
>>>>>>>>> add
>>>>>>>>> to
>>>>>>>> CouchDB ddocs and focus on an in-browser tool (add features to
>>>>>>>> Fauxton)
>>>>>>>> that removes the need for new developers to learn git and
>>>>>>>> build
>>>>>>>> tools
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Giovanni Lenzi
>>>>>> www.smileupps.com
>>>>>> Smileupps Cloud App Store
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> In theory, there is no difference between theory and practice.
>>>> In practice, there is.   .... Yogi Berra
>>>> 
>>>> 
>>> 
>> 
> 
> 
> 
> -- 
> 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

Re: the future of couchapp

[Andy Wenk <an...@apache.org>]

Joan, thanks a lot for your reminder. This is very well received and I
think the majority of people of this thread do understand, that the Apache
CouchDB project is definitely not comparable to "business".

The goal of the marketing list is more than often defined. This list is for
spreading the word about CouchDB like with information in the wiki, logo
stuff, the story of CouchDB, weekly news and so on. As in every Apache
project, the dev@ mailing-list is THE place to discuss any features for
Apache CouchDB.

One word to CouchApps. I am very happy about the discussion about
CouchApps. And I am strongly supporting everyone who is building stuff with
it. Like smileupps is doing. CouchApps have their historical place in
Apache CouchDB. But the way we will support CouchApps further - be it the
naming or sth else - is a completely different story.

So let's separate the topics to the appropriate ML and keep on moving.

All the best

Andy

On 9 May 2015 at 21:25, Joan Touzet <wo...@apache.org> wrote:

> One additional data point here. I mention "serious customers" as
> narrowly defined in this email as the thousands-to-millions of $
> customers. CouchApps probably have a place in the lower end of the
> market, i.e. shared instance users who have lightweight needs for
> their applications and are customers of IrisCouch or SmileApps. I
> wasn't trying to say there isn't a market for this :) The business
> case to be made for them is very different, i.e. razor thin margins
> across thousands to millions of people. Such an approach wasn't
> logical for Cloudant - the shared instances don't drive the company
> like the dedicated instances do. Because of this data I think
> CouchApps as a primary user story is very hard road to walk for us.
>
> ----- Original Message -----
> > From: "Joan Touzet" <wo...@apache.org>
> > To: marketing@couchdb.apache.org
> > Cc: "Mike Broberg" <mb...@us.ibm.com>, smetson@uk.ibm.com
> > Sent: Saturday, May 9, 2015 2:26:26 PM
> > Subject: Re: the future of couchapp
> >
> > Hi Miles,
> >
> > DISCLAIMER: I am not speaking as an official representative of IBM or
> > Cloudant. I have cc'ed Mike Broberg, who can speak for them if
> > necessary. (I also want him to be aware of what I am saying here).
> >
> > *** TL;DR: the people who are willing to spend anywhere from
> > thousands to millions of dollars on a CouchDB-based solution aren't
> > interested in CouchApps. I think the discussion to date is missing
> > this, and as such, is entirely unrepresentative of the current
> > market for Apache CouchDB.
> >
> > The answer is that there are practically no customers of Cloudant/IBM
> > who are banking on CouchApps for any serious need. Every client that
> > I can think of - meaning they have a dedicated cluster, and aren't
> > using the shared cluster service - are using either a traditional
> > three-tier app server structure (Node.JS, Python, PHP, Ruby, Java,
> > .NET, etc.) or are doing client-side development on mobile platforms
> > (iOS + TouchDB, Android + PouchDB) where they are replicating back to
> > the Cloudant clusters for data exchange. In all of these scenarios,
> > replication is the "killer feature" for CouchDB, with the REST
> > interface a close second, and the ease of unstructured JSON data as
> > a third.
> >
> > Cloudant built out a document-level (and field-level!) security
> > solution for one customer, about two years ago now. While there was
> > initial interest, performance considerations lead to the solution
> > being backburnered for further consideration. Even in that situation,
> > CouchApps weren't the primary concern -- database-level enforcement
> > of security rules *was*.
> >
> > Within Cloudant, perhaps Simon Metson was the primary proponent of
> > using CouchApps for serious purposes. He used them in the "For
> > Developers" section of the website to help demonstrate various key
> > features of the platform, including the new MongoDB-inspired Mango
> > feature that's now a part of CouchDB 2.0. Diana Thayer (@garbados)
> > picked up on this and built a documentation framework on top of
> > CouchApps. This, to me, is perhaps the ideal use of CouchApps:
> > unsecured content, read-only, displayed in different formats based
> > upon what the end user needs, and self-hosted by CouchDB (so you
> > can view the product's documentation using the product itself).
> > More information on this use is at:
> >
> >
> https://mail-archives.apache.org/mod_mbox/couchdb-dev/201410.mbox/%3C28603443.66.1414446738764.JavaMail.joant@Joans-MacBook-Pro.local%3E
> >
> >
> >
> >
> >
> > ----- Original Message -----
> > > From: "Miles Fidelman" <mf...@meetinghouse.net>
> > > To: marketing@couchdb.apache.org
> > > Sent: Friday, May 8, 2015 11:21:28 AM
> > > Subject: Re: the future of couchapp
> > >
> > > Let's be clear.
> > > (Good) marketing isn't about selling a solution to folks who don't
> > > have
> > > a problem in the first place, it's about it's identifying problems
> > > for
> > > which we offer a solution.
> > >
> > > And.. it occurs to me that Cloudant has been doing market research
> > > and
> > > "real" marketing - perhaps some folks from Cloudant might share
> > > some
> > > findings related to CouchDB (as opposed to those that might relate
> > > to
> > > their commercial extensions and services)?
> > >
> > > Miles Fidelman
> > >
> > >
> > >
> > > Giovanni Lenzi wrote:
> > > >> translates user@ decisions in "how to drive them to the public"?
> > > > or maybe better how to drive dev@ implemented features to the
> > > > public ?
> > > >
> > > > 2015-05-08 16:57 GMT+02:00 Giovanni Lenzi
> > > > <g....@smileupps.com>:
> > > >
> > > >> Got it, Joan. Thanks for the useful reminder, considered I am a
> > > >> total
> > > >> newbie here, I definitely don't know how decision-making process
> > > >> is driven.
> > > >>
> > > >> We will cut the "features" part from this discussion then and
> > > >> take
> > > >> it to
> > > >> the devs@ list
> > > >>
> > > >> Here we should then focus on @jan's request about the story for
> > > >> couchapps.. given that until 2 days ago that was somehow
> > > >> uncertain
> > > >>
> > > >> But I think too this is more a user@ topic... isn't maybe
> > > >> marketing more
> > > >> appropriate to translates user@ decisions in "how to drive them
> > > >> to
> > > >> the
> > > >> public"? If you all agree with that, you can move this
> > > >> discussion
> > > >> to user@
> > > >> or dev@, don't know what is preferable.
> > > >>
> > > >>
> > > >> 2015-05-08 15:56 GMT+02:00 Joan Touzet <wo...@apache.org>:
> > > >>
> > > >>> Hi all,
> > > >>>
> > > >>> PMC hat on...
> > > >>>
> > > >>> Reminding you *again* that we should not be using the MARKETING
> > > >>> list to
> > > >>> discuss new FEATURES and functionality for Apache CouchDB. We
> > > >>> are
> > > >>> not
> > > >>> like a company where marketing makes up what they want to do,
> > > >>> and
> > > >>> development is forced to implement it. While it's a good idea
> > > >>> to
> > > >>> have a
> > > >>> feedback loop between marketing and development, I am
> > > >>> especially
> > > >>> keen to
> > > >>> not see Apache CouchDB turn into a marketing-driven development
> > > >>> effort.
> > > >>>
> > > >>> If you are proposing new CouchDB features, please make those
> > > >>> proposals
> > > >>> on the dev@ mailing list. And if you are willing to *develop*
> > > >>> and
> > > >>> *support* those functions - even better. Current CouchDB
> > > >>> development
> > > >>> bandwidth is extremely limited, and would best be served by
> > > >>> helping you
> > > >>> to understand the current design's constraints, and the
> > > >>> difficulties
> > > >>> that may be inherent in what you ask for.
> > > >>>
> > > >>> Best regards,
> > > >>> Joan
> > > >>>
> > > >>> ----- Original Message -----
> > > >>>> From: "Giovanni Lenzi" <g....@smileupps.com>
> > > >>>> To: marketing@couchdb.apache.org
> > > >>>> Sent: Friday, May 8, 2015 4:05:12 AM
> > > >>>> Subject: Re: the future of couchapp
> > > >>>>
> > > >>>>> A service-trigger feature could be one of the new features of
> > > >>>>> Couch
> > > >>>>> apps.
> > > >>>> if possible, would be awesome :)
> > > >>>>
> > > >>>>> some clear design goals and a very limited set of features to
> > > >>>>> add
> > > >>>>> to
> > > >>>> CouchDB ddocs and focus on an in-browser tool (add features to
> > > >>>> Fauxton)
> > > >>>> that removes the need for new developers to learn git and
> > > >>>> build
> > > >>>> tools
> > > >>
> > > >>
> > > >> --
> > > >> Giovanni Lenzi
> > > >> www.smileupps.com
> > > >> Smileupps Cloud App Store
> > > >>
> > > >
> > > >
> > >
> > >
> > > --
> > > In theory, there is no difference between theory and practice.
> > > In practice, there is.   .... Yogi Berra
> > >
> > >
> >
>



-- 
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

Re: the future of couchapp

[Joan Touzet <wo...@apache.org>]

One additional data point here. I mention "serious customers" as
narrowly defined in this email as the thousands-to-millions of $
customers. CouchApps probably have a place in the lower end of the
market, i.e. shared instance users who have lightweight needs for
their applications and are customers of IrisCouch or SmileApps. I
wasn't trying to say there isn't a market for this :) The business
case to be made for them is very different, i.e. razor thin margins
across thousands to millions of people. Such an approach wasn't
logical for Cloudant - the shared instances don't drive the company
like the dedicated instances do. Because of this data I think
CouchApps as a primary user story is very hard road to walk for us.

----- Original Message -----
> From: "Joan Touzet" <wo...@apache.org>
> To: marketing@couchdb.apache.org
> Cc: "Mike Broberg" <mb...@us.ibm.com>, smetson@uk.ibm.com
> Sent: Saturday, May 9, 2015 2:26:26 PM
> Subject: Re: the future of couchapp
> 
> Hi Miles,
> 
> DISCLAIMER: I am not speaking as an official representative of IBM or
> Cloudant. I have cc'ed Mike Broberg, who can speak for them if
> necessary. (I also want him to be aware of what I am saying here).
> 
> *** TL;DR: the people who are willing to spend anywhere from
> thousands to millions of dollars on a CouchDB-based solution aren't
> interested in CouchApps. I think the discussion to date is missing
> this, and as such, is entirely unrepresentative of the current
> market for Apache CouchDB.
> 
> The answer is that there are practically no customers of Cloudant/IBM
> who are banking on CouchApps for any serious need. Every client that
> I can think of - meaning they have a dedicated cluster, and aren't
> using the shared cluster service - are using either a traditional
> three-tier app server structure (Node.JS, Python, PHP, Ruby, Java,
> .NET, etc.) or are doing client-side development on mobile platforms
> (iOS + TouchDB, Android + PouchDB) where they are replicating back to
> the Cloudant clusters for data exchange. In all of these scenarios,
> replication is the "killer feature" for CouchDB, with the REST
> interface a close second, and the ease of unstructured JSON data as
> a third.
> 
> Cloudant built out a document-level (and field-level!) security
> solution for one customer, about two years ago now. While there was
> initial interest, performance considerations lead to the solution
> being backburnered for further consideration. Even in that situation,
> CouchApps weren't the primary concern -- database-level enforcement
> of security rules *was*.
> 
> Within Cloudant, perhaps Simon Metson was the primary proponent of
> using CouchApps for serious purposes. He used them in the "For
> Developers" section of the website to help demonstrate various key
> features of the platform, including the new MongoDB-inspired Mango
> feature that's now a part of CouchDB 2.0. Diana Thayer (@garbados)
> picked up on this and built a documentation framework on top of
> CouchApps. This, to me, is perhaps the ideal use of CouchApps:
> unsecured content, read-only, displayed in different formats based
> upon what the end user needs, and self-hosted by CouchDB (so you
> can view the product's documentation using the product itself).
> More information on this use is at:
> 
> https://mail-archives.apache.org/mod_mbox/couchdb-dev/201410.mbox/%3C28603443.66.1414446738764.JavaMail.joant@Joans-MacBook-Pro.local%3E
> 
> 
> 
> 
> 
> ----- Original Message -----
> > From: "Miles Fidelman" <mf...@meetinghouse.net>
> > To: marketing@couchdb.apache.org
> > Sent: Friday, May 8, 2015 11:21:28 AM
> > Subject: Re: the future of couchapp
> > 
> > Let's be clear.
> > (Good) marketing isn't about selling a solution to folks who don't
> > have
> > a problem in the first place, it's about it's identifying problems
> > for
> > which we offer a solution.
> > 
> > And.. it occurs to me that Cloudant has been doing market research
> > and
> > "real" marketing - perhaps some folks from Cloudant might share
> > some
> > findings related to CouchDB (as opposed to those that might relate
> > to
> > their commercial extensions and services)?
> > 
> > Miles Fidelman
> > 
> > 
> > 
> > Giovanni Lenzi wrote:
> > >> translates user@ decisions in "how to drive them to the public"?
> > > or maybe better how to drive dev@ implemented features to the
> > > public ?
> > >
> > > 2015-05-08 16:57 GMT+02:00 Giovanni Lenzi
> > > <g....@smileupps.com>:
> > >
> > >> Got it, Joan. Thanks for the useful reminder, considered I am a
> > >> total
> > >> newbie here, I definitely don't know how decision-making process
> > >> is driven.
> > >>
> > >> We will cut the "features" part from this discussion then and
> > >> take
> > >> it to
> > >> the devs@ list
> > >>
> > >> Here we should then focus on @jan's request about the story for
> > >> couchapps.. given that until 2 days ago that was somehow
> > >> uncertain
> > >>
> > >> But I think too this is more a user@ topic... isn't maybe
> > >> marketing more
> > >> appropriate to translates user@ decisions in "how to drive them
> > >> to
> > >> the
> > >> public"? If you all agree with that, you can move this
> > >> discussion
> > >> to user@
> > >> or dev@, don't know what is preferable.
> > >>
> > >>
> > >> 2015-05-08 15:56 GMT+02:00 Joan Touzet <wo...@apache.org>:
> > >>
> > >>> Hi all,
> > >>>
> > >>> PMC hat on...
> > >>>
> > >>> Reminding you *again* that we should not be using the MARKETING
> > >>> list to
> > >>> discuss new FEATURES and functionality for Apache CouchDB. We
> > >>> are
> > >>> not
> > >>> like a company where marketing makes up what they want to do,
> > >>> and
> > >>> development is forced to implement it. While it's a good idea
> > >>> to
> > >>> have a
> > >>> feedback loop between marketing and development, I am
> > >>> especially
> > >>> keen to
> > >>> not see Apache CouchDB turn into a marketing-driven development
> > >>> effort.
> > >>>
> > >>> If you are proposing new CouchDB features, please make those
> > >>> proposals
> > >>> on the dev@ mailing list. And if you are willing to *develop*
> > >>> and
> > >>> *support* those functions - even better. Current CouchDB
> > >>> development
> > >>> bandwidth is extremely limited, and would best be served by
> > >>> helping you
> > >>> to understand the current design's constraints, and the
> > >>> difficulties
> > >>> that may be inherent in what you ask for.
> > >>>
> > >>> Best regards,
> > >>> Joan
> > >>>
> > >>> ----- Original Message -----
> > >>>> From: "Giovanni Lenzi" <g....@smileupps.com>
> > >>>> To: marketing@couchdb.apache.org
> > >>>> Sent: Friday, May 8, 2015 4:05:12 AM
> > >>>> Subject: Re: the future of couchapp
> > >>>>
> > >>>>> A service-trigger feature could be one of the new features of
> > >>>>> Couch
> > >>>>> apps.
> > >>>> if possible, would be awesome :)
> > >>>>
> > >>>>> some clear design goals and a very limited set of features to
> > >>>>> add
> > >>>>> to
> > >>>> CouchDB ddocs and focus on an in-browser tool (add features to
> > >>>> Fauxton)
> > >>>> that removes the need for new developers to learn git and
> > >>>> build
> > >>>> tools
> > >>
> > >>
> > >> --
> > >> Giovanni Lenzi
> > >> www.smileupps.com
> > >> Smileupps Cloud App Store
> > >>
> > >
> > >
> > 
> > 
> > --
> > In theory, there is no difference between theory and practice.
> > In practice, there is.   .... Yogi Berra
> > 
> > 
> 

Re: the future of couchapp

[Joan Touzet <wo...@apache.org>]

Hi Miles,

DISCLAIMER: I am not speaking as an official representative of IBM or
Cloudant. I have cc'ed Mike Broberg, who can speak for them if
necessary. (I also want him to be aware of what I am saying here).

*** TL;DR: the people who are willing to spend anywhere from
thousands to millions of dollars on a CouchDB-based solution aren't
interested in CouchApps. I think the discussion to date is missing
this, and as such, is entirely unrepresentative of the current
market for Apache CouchDB.

The answer is that there are practically no customers of Cloudant/IBM
who are banking on CouchApps for any serious need. Every client that
I can think of - meaning they have a dedicated cluster, and aren't
using the shared cluster service - are using either a traditional
three-tier app server structure (Node.JS, Python, PHP, Ruby, Java,
.NET, etc.) or are doing client-side development on mobile platforms
(iOS + TouchDB, Android + PouchDB) where they are replicating back to
the Cloudant clusters for data exchange. In all of these scenarios,
replication is the "killer feature" for CouchDB, with the REST
interface a close second, and the ease of unstructured JSON data as
a third.

Cloudant built out a document-level (and field-level!) security
solution for one customer, about two years ago now. While there was
initial interest, performance considerations lead to the solution
being backburnered for further consideration. Even in that situation,
CouchApps weren't the primary concern -- database-level enforcement
of security rules *was*.

Within Cloudant, perhaps Simon Metson was the primary proponent of
using CouchApps for serious purposes. He used them in the "For
Developers" section of the website to help demonstrate various key
features of the platform, including the new MongoDB-inspired Mango
feature that's now a part of CouchDB 2.0. Diana Thayer (@garbados)
picked up on this and built a documentation framework on top of
CouchApps. This, to me, is perhaps the ideal use of CouchApps:
unsecured content, read-only, displayed in different formats based
upon what the end user needs, and self-hosted by CouchDB (so you
can view the product's documentation using the product itself).
More information on this use is at:

https://mail-archives.apache.org/mod_mbox/couchdb-dev/201410.mbox/%3C28603443.66.1414446738764.JavaMail.joant@Joans-MacBook-Pro.local%3E





----- Original Message -----
> From: "Miles Fidelman" <mf...@meetinghouse.net>
> To: marketing@couchdb.apache.org
> Sent: Friday, May 8, 2015 11:21:28 AM
> Subject: Re: the future of couchapp
> 
> Let's be clear.
> (Good) marketing isn't about selling a solution to folks who don't
> have
> a problem in the first place, it's about it's identifying problems
> for
> which we offer a solution.
> 
> And.. it occurs to me that Cloudant has been doing market research
> and
> "real" marketing - perhaps some folks from Cloudant might share some
> findings related to CouchDB (as opposed to those that might relate to
> their commercial extensions and services)?
> 
> Miles Fidelman
> 
> 
> 
> Giovanni Lenzi wrote:
> >> translates user@ decisions in "how to drive them to the public"?
> > or maybe better how to drive dev@ implemented features to the
> > public ?
> >
> > 2015-05-08 16:57 GMT+02:00 Giovanni Lenzi <g....@smileupps.com>:
> >
> >> Got it, Joan. Thanks for the useful reminder, considered I am a
> >> total
> >> newbie here, I definitely don't know how decision-making process
> >> is driven.
> >>
> >> We will cut the "features" part from this discussion then and take
> >> it to
> >> the devs@ list
> >>
> >> Here we should then focus on @jan's request about the story for
> >> couchapps.. given that until 2 days ago that was somehow uncertain
> >>
> >> But I think too this is more a user@ topic... isn't maybe
> >> marketing more
> >> appropriate to translates user@ decisions in "how to drive them to
> >> the
> >> public"? If you all agree with that, you can move this discussion
> >> to user@
> >> or dev@, don't know what is preferable.
> >>
> >>
> >> 2015-05-08 15:56 GMT+02:00 Joan Touzet <wo...@apache.org>:
> >>
> >>> Hi all,
> >>>
> >>> PMC hat on...
> >>>
> >>> Reminding you *again* that we should not be using the MARKETING
> >>> list to
> >>> discuss new FEATURES and functionality for Apache CouchDB. We are
> >>> not
> >>> like a company where marketing makes up what they want to do, and
> >>> development is forced to implement it. While it's a good idea to
> >>> have a
> >>> feedback loop between marketing and development, I am especially
> >>> keen to
> >>> not see Apache CouchDB turn into a marketing-driven development
> >>> effort.
> >>>
> >>> If you are proposing new CouchDB features, please make those
> >>> proposals
> >>> on the dev@ mailing list. And if you are willing to *develop* and
> >>> *support* those functions - even better. Current CouchDB
> >>> development
> >>> bandwidth is extremely limited, and would best be served by
> >>> helping you
> >>> to understand the current design's constraints, and the
> >>> difficulties
> >>> that may be inherent in what you ask for.
> >>>
> >>> Best regards,
> >>> Joan
> >>>
> >>> ----- Original Message -----
> >>>> From: "Giovanni Lenzi" <g....@smileupps.com>
> >>>> To: marketing@couchdb.apache.org
> >>>> Sent: Friday, May 8, 2015 4:05:12 AM
> >>>> Subject: Re: the future of couchapp
> >>>>
> >>>>> A service-trigger feature could be one of the new features of
> >>>>> Couch
> >>>>> apps.
> >>>> if possible, would be awesome :)
> >>>>
> >>>>> some clear design goals and a very limited set of features to
> >>>>> add
> >>>>> to
> >>>> CouchDB ddocs and focus on an in-browser tool (add features to
> >>>> Fauxton)
> >>>> that removes the need for new developers to learn git and build
> >>>> tools
> >>
> >>
> >> --
> >> Giovanni Lenzi
> >> www.smileupps.com
> >> Smileupps Cloud App Store
> >>
> >
> >
> 
> 
> --
> In theory, there is no difference between theory and practice.
> In practice, there is.   .... Yogi Berra
> 
> 

Re: the future of couchapp

[Miles Fidelman <mf...@meetinghouse.net>]

Let's be clear.
(Good) marketing isn't about selling a solution to folks who don't have 
a problem in the first place, it's about it's identifying problems for 
which we offer a solution.

And.. it occurs to me that Cloudant has been doing market research and 
"real" marketing - perhaps some folks from Cloudant might share some 
findings related to CouchDB (as opposed to those that might relate to 
their commercial extensions and services)?

Miles Fidelman



Giovanni Lenzi wrote:
>> translates user@ decisions in "how to drive them to the public"?
> or maybe better how to drive dev@ implemented features to the public ?
>
> 2015-05-08 16:57 GMT+02:00 Giovanni Lenzi <g....@smileupps.com>:
>
>> Got it, Joan. Thanks for the useful reminder, considered I am a total
>> newbie here, I definitely don't know how decision-making process is driven.
>>
>> We will cut the "features" part from this discussion then and take it to
>> the devs@ list
>>
>> Here we should then focus on @jan's request about the story for
>> couchapps.. given that until 2 days ago that was somehow uncertain
>>
>> But I think too this is more a user@ topic... isn't maybe marketing more
>> appropriate to translates user@ decisions in "how to drive them to the
>> public"? If you all agree with that, you can move this discussion to user@
>> or dev@, don't know what is preferable.
>>
>>
>> 2015-05-08 15:56 GMT+02:00 Joan Touzet <wo...@apache.org>:
>>
>>> Hi all,
>>>
>>> PMC hat on...
>>>
>>> Reminding you *again* that we should not be using the MARKETING list to
>>> discuss new FEATURES and functionality for Apache CouchDB. We are not
>>> like a company where marketing makes up what they want to do, and
>>> development is forced to implement it. While it's a good idea to have a
>>> feedback loop between marketing and development, I am especially keen to
>>> not see Apache CouchDB turn into a marketing-driven development effort.
>>>
>>> If you are proposing new CouchDB features, please make those proposals
>>> on the dev@ mailing list. And if you are willing to *develop* and
>>> *support* those functions - even better. Current CouchDB development
>>> bandwidth is extremely limited, and would best be served by helping you
>>> to understand the current design's constraints, and the difficulties
>>> that may be inherent in what you ask for.
>>>
>>> Best regards,
>>> Joan
>>>
>>> ----- Original Message -----
>>>> From: "Giovanni Lenzi" <g....@smileupps.com>
>>>> To: marketing@couchdb.apache.org
>>>> Sent: Friday, May 8, 2015 4:05:12 AM
>>>> Subject: Re: the future of couchapp
>>>>
>>>>> A service-trigger feature could be one of the new features of Couch
>>>>> apps.
>>>> if possible, would be awesome :)
>>>>
>>>>> some clear design goals and a very limited set of features to add
>>>>> to
>>>> CouchDB ddocs and focus on an in-browser tool (add features to
>>>> Fauxton)
>>>> that removes the need for new developers to learn git and build tools
>>
>>
>> --
>> Giovanni Lenzi
>> www.smileupps.com
>> Smileupps Cloud App Store
>>
>
>


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

Re: the future of couchapp

[Giovanni Lenzi <g....@smileupps.com>]

> translates user@ decisions in "how to drive them to the public"?

or maybe better how to drive dev@ implemented features to the public ?

2015-05-08 16:57 GMT+02:00 Giovanni Lenzi <g....@smileupps.com>:

> Got it, Joan. Thanks for the useful reminder, considered I am a total
> newbie here, I definitely don't know how decision-making process is driven.
>
> We will cut the "features" part from this discussion then and take it to
> the devs@ list
>
> Here we should then focus on @jan's request about the story for
> couchapps.. given that until 2 days ago that was somehow uncertain
>
> But I think too this is more a user@ topic... isn't maybe marketing more
> appropriate to translates user@ decisions in "how to drive them to the
> public"? If you all agree with that, you can move this discussion to user@
> or dev@, don't know what is preferable.
>
>
> 2015-05-08 15:56 GMT+02:00 Joan Touzet <wo...@apache.org>:
>
>> Hi all,
>>
>> PMC hat on...
>>
>> Reminding you *again* that we should not be using the MARKETING list to
>> discuss new FEATURES and functionality for Apache CouchDB. We are not
>> like a company where marketing makes up what they want to do, and
>> development is forced to implement it. While it's a good idea to have a
>> feedback loop between marketing and development, I am especially keen to
>> not see Apache CouchDB turn into a marketing-driven development effort.
>>
>> If you are proposing new CouchDB features, please make those proposals
>> on the dev@ mailing list. And if you are willing to *develop* and
>> *support* those functions - even better. Current CouchDB development
>> bandwidth is extremely limited, and would best be served by helping you
>> to understand the current design's constraints, and the difficulties
>> that may be inherent in what you ask for.
>>
>> Best regards,
>> Joan
>>
>> ----- Original Message -----
>> > From: "Giovanni Lenzi" <g....@smileupps.com>
>> > To: marketing@couchdb.apache.org
>> > Sent: Friday, May 8, 2015 4:05:12 AM
>> > Subject: Re: the future of couchapp
>> >
>> > > A service-trigger feature could be one of the new features of Couch
>> > > apps.
>> >
>> > if possible, would be awesome :)
>> >
>> > > some clear design goals and a very limited set of features to add
>> > > to
>> > CouchDB ddocs and focus on an in-browser tool (add features to
>> > Fauxton)
>> > that removes the need for new developers to learn git and build tools
>>
>
>
>
> --
> Giovanni Lenzi
> www.smileupps.com
> Smileupps Cloud App Store
>



-- 
Giovanni Lenzi
www.smileupps.com
Smileupps Cloud App Store

Re: the future of couchapp

[Giovanni Lenzi <g....@smileupps.com>]

Got it, Joan. Thanks for the useful reminder, considered I am a total
newbie here, I definitely don't know how decision-making process is driven.

We will cut the "features" part from this discussion then and take it to
the devs@ list

Here we should then focus on @jan's request about the story for couchapps..
given that until 2 days ago that was somehow uncertain

But I think too this is more a user@ topic... isn't maybe marketing more
appropriate to translates user@ decisions in "how to drive them to the
public"? If you all agree with that, you can move this discussion to user@
or dev@, don't know what is preferable.


2015-05-08 15:56 GMT+02:00 Joan Touzet <wo...@apache.org>:

> Hi all,
>
> PMC hat on...
>
> Reminding you *again* that we should not be using the MARKETING list to
> discuss new FEATURES and functionality for Apache CouchDB. We are not
> like a company where marketing makes up what they want to do, and
> development is forced to implement it. While it's a good idea to have a
> feedback loop between marketing and development, I am especially keen to
> not see Apache CouchDB turn into a marketing-driven development effort.
>
> If you are proposing new CouchDB features, please make those proposals
> on the dev@ mailing list. And if you are willing to *develop* and
> *support* those functions - even better. Current CouchDB development
> bandwidth is extremely limited, and would best be served by helping you
> to understand the current design's constraints, and the difficulties
> that may be inherent in what you ask for.
>
> Best regards,
> Joan
>
> ----- Original Message -----
> > From: "Giovanni Lenzi" <g....@smileupps.com>
> > To: marketing@couchdb.apache.org
> > Sent: Friday, May 8, 2015 4:05:12 AM
> > Subject: Re: the future of couchapp
> >
> > > A service-trigger feature could be one of the new features of Couch
> > > apps.
> >
> > if possible, would be awesome :)
> >
> > > some clear design goals and a very limited set of features to add
> > > to
> > CouchDB ddocs and focus on an in-browser tool (add features to
> > Fauxton)
> > that removes the need for new developers to learn git and build tools
>



-- 
Giovanni Lenzi
www.smileupps.com
Smileupps Cloud App Store

Re: the future of couchapp

[Joan Touzet <wo...@apache.org>]

Johs,

This is a *volunteer* project, worked on by people who are donating
their time and effort to build the software. If you force them to
work on things they don't want to work on, they'll leave.

In a business setting, I agree - but this isn't a business, not even
for a majority of people working on the project, including Cloudant
employees.

-Joan

----- Original Message -----
> From: "Johs Ensby" <jo...@b2w.com>
> To: marketing@couchdb.apache.org, "Joan Touzet" <wo...@apache.org>
> Sent: Friday, May 8, 2015 10:22:23 AM
> Subject: Re: the future of couchapp
> 
> Joan,
> Before marketing concept was invented in the 60’s  factories made
> products and sales people knocked on doors to sell them.
> Your ground rules are outdated by 75 years, I am afraid.
> Johs
> 
> 
> > On 08 May 2015, at 15:56, Joan Touzet <wo...@apache.org> wrote:
> > 
> > Hi all,
> > 
> > PMC hat on...
> > 
> > Reminding you *again* that we should not be using the MARKETING
> > list to
> > discuss new FEATURES and functionality for Apache CouchDB. We are
> > not
> > like a company where marketing makes up what they want to do, and
> > development is forced to implement it. While it's a good idea to
> > have a
> > feedback loop between marketing and development, I am especially
> > keen to
> > not see Apache CouchDB turn into a marketing-driven development
> > effort.
> > 
> > If you are proposing new CouchDB features, please make those
> > proposals
> > on the dev@ mailing list. And if you are willing to *develop* and
> > *support* those functions - even better. Current CouchDB
> > development
> > bandwidth is extremely limited, and would best be served by helping
> > you
> > to understand the current design's constraints, and the
> > difficulties
> > that may be inherent in what you ask for.
> > 
> > Best regards,
> > Joan
> > 
> > ----- Original Message -----
> >> From: "Giovanni Lenzi" <g....@smileupps.com>
> >> To: marketing@couchdb.apache.org
> >> Sent: Friday, May 8, 2015 4:05:12 AM
> >> Subject: Re: the future of couchapp
> >> 
> >>> A service-trigger feature could be one of the new features of
> >>> Couch
> >>> apps.
> >> 
> >> if possible, would be awesome :)
> >> 
> >>> some clear design goals and a very limited set of features to add
> >>> to
> >> CouchDB ddocs and focus on an in-browser tool (add features to
> >> Fauxton)
> >> that removes the need for new developers to learn git and build
> >> tools
> 
> 

Re: the future of couchapp

[Johs Ensby <jo...@b2w.com>]

Joan, 
Before marketing concept was invented in the 60’s  factories made products and sales people knocked on doors to sell them.
Your ground rules are outdated by 75 years, I am afraid.
Johs 


> On 08 May 2015, at 15:56, Joan Touzet <wo...@apache.org> wrote:
> 
> Hi all,
> 
> PMC hat on...
> 
> Reminding you *again* that we should not be using the MARKETING list to
> discuss new FEATURES and functionality for Apache CouchDB. We are not
> like a company where marketing makes up what they want to do, and
> development is forced to implement it. While it's a good idea to have a
> feedback loop between marketing and development, I am especially keen to
> not see Apache CouchDB turn into a marketing-driven development effort.
> 
> If you are proposing new CouchDB features, please make those proposals
> on the dev@ mailing list. And if you are willing to *develop* and
> *support* those functions - even better. Current CouchDB development
> bandwidth is extremely limited, and would best be served by helping you
> to understand the current design's constraints, and the difficulties
> that may be inherent in what you ask for.
> 
> Best regards,
> Joan
> 
> ----- Original Message -----
>> From: "Giovanni Lenzi" <g....@smileupps.com>
>> To: marketing@couchdb.apache.org
>> Sent: Friday, May 8, 2015 4:05:12 AM
>> Subject: Re: the future of couchapp
>> 
>>> A service-trigger feature could be one of the new features of Couch
>>> apps.
>> 
>> if possible, would be awesome :)
>> 
>>> some clear design goals and a very limited set of features to add
>>> to
>> CouchDB ddocs and focus on an in-browser tool (add features to
>> Fauxton)
>> that removes the need for new developers to learn git and build tools

Re: the future of couchapp

[Joan Touzet <wo...@apache.org>]

Hi all,

PMC hat on...

Reminding you *again* that we should not be using the MARKETING list to
discuss new FEATURES and functionality for Apache CouchDB. We are not
like a company where marketing makes up what they want to do, and
development is forced to implement it. While it's a good idea to have a
feedback loop between marketing and development, I am especially keen to
not see Apache CouchDB turn into a marketing-driven development effort.

If you are proposing new CouchDB features, please make those proposals
on the dev@ mailing list. And if you are willing to *develop* and
*support* those functions - even better. Current CouchDB development
bandwidth is extremely limited, and would best be served by helping you
to understand the current design's constraints, and the difficulties
that may be inherent in what you ask for.

Best regards,
Joan

----- Original Message -----
> From: "Giovanni Lenzi" <g....@smileupps.com>
> To: marketing@couchdb.apache.org
> Sent: Friday, May 8, 2015 4:05:12 AM
> Subject: Re: the future of couchapp
> 
> > A service-trigger feature could be one of the new features of Couch
> > apps.
> 
> if possible, would be awesome :)
> 
> > some clear design goals and a very limited set of features to add
> > to
> CouchDB ddocs and focus on an in-browser tool (add features to
> Fauxton)
> that removes the need for new developers to learn git and build tools

Re: the future of couchapp

[Johs Ensby <jo...@b2w.com>]

Giovanni,
I would like to here Jan’s take on this, but my understanding is
“the story” (or narrative) for CouchApp

is a tool for conceptualizing and giving the thing an identity, define its scope and purpose in a way that is easy to grasp.

A definition would be similar, but without the flavour.

A lot of the input in this discussion is about the confusion driven by so many conflicting concepts, hence the need for a story - to me the best thing would for it to be a sub story of a good story about CouchDB
Johs



> On 08 May 2015, at 10:05, Giovanni Lenzi <g....@smileupps.com> wrote:
> 
> All of these are nice, but probably I'm missing what concretely we want
> from this discussion? Some content to be written? where? on CouchDB
> homepage? How many lines? Maybe @Jan can clarify better what he means in
> concrete with "creating a story"?

Re: the future of couchapp

[Giovanni Lenzi <g....@smileupps.com>]

> A service-trigger feature could be one of the new features of Couch apps.

if possible, would be awesome :)

> some clear design goals and a very limited set of features to add to
CouchDB ddocs and focus on an in-browser tool (add features to Fauxton)
that removes the need for new developers to learn git and build tools

I agree, I think @ermouth 3 points could be one of the way to go. He was
also proposing its editor provided as a couchapp or, even better, to be
added to Fauxton. http://cloudwall.me/etc/json-editor.html
To me his tool is powerful because it goes in the "simplicity always win"
direction. It allows to create/modify a json(and so a ddoc) with an
intuitive ui and with attachments upload feature too, which are all the
pieces needed to create any kind of ddoc. IMHO, creating an alternative
editor, maybe easier-to-use for beginners, would be too limiting for
developers and complicated in vain.
If, and when, @ermouth editor will be in place, it would only be a matter
of creating concrete examples/tutorials, targeting different skill levels,
explaining how and which ddoc fields to fill in for different type of
couchapps.

>CouchDB is the web done right
>CouchDB doesn’t want to be your database; it wants to be your web site.
> focus on Nolan’s perspective; the simplicity-wins opportunity.
>We could also take the approach of promoting a new stack
>Of course you can used CouchDB in a multi-tier architecture with any stack
of technologies you like.
>But you can also create and deploy apps and web sites with CouchDB alone.
>A couch app provides a UI for your data and can trigger services that can
do anything you want with the data.

All of these are nice, but probably I'm missing what concretely we want
from this discussion? Some content to be written? where? on CouchDB
homepage? How many lines? Maybe @Jan can clarify better what he means in
concrete with "creating a story"?



2015-05-08 9:10 GMT+02:00 Johs Ensby <jo...@b2w.com>:

> Giovanni,
> I think it is unrealistic to make Couch apps part of the main story of
> CouchDB
> The CouchDB story need to start with DB (ala “data where you need it”)
> Then we should be looking for the “one more thing” kind of story (ala
> Steve Jobs’ nuggets at his keynotes) that top off the story about the DB.
>
> The one-more-thing story would should not diminish are contradict the DB
> story.
>
> I looked up Nolan Lawson’s (@nolanlawson) enthusiastic blog post from 2013
> http://nolanlawson.com/2013/11/15/couchdb-doesnt-want-to-be-your-database-it-wants-to-be-your-web-site/
> <
> http://nolanlawson.com/2013/11/15/couchdb-doesnt-want-to-be-your-database-it-wants-to-be-your-web-site/
> >
> and pull som highlights from that:
>
> ========================
>
> He quotes Chris Anderson (@jchris)
> Because CouchDB is a web server, you can serve applications directly [to]
> the browser without any middle tier. When I’m feeling punchy, I like to
> call the traditional application server stack “extra code to make CouchDB
> uglier and slower.”
>
> Nolan’s epiphany:
> No wait, CouchDB is a miracle
> See, here I was, using client-side Javascript to talk to Express to talk
> to Node to talk to Nano to talk to Couch, and at each step I was converting
> parameter names from underscores to camel case (or whatever my petty
> hangups are), all the while introducing bugs as I tried to make each layer
> fit nicely with the next one. And I had a working web server right in front
> of me! CouchDB! Why not just call it directly, you fool?! (I shout at
> myself in hindsight.)
> […]
> CouchDB is the web done right
> And in fact, CouchDB is better than HTTP, because CouchDB actually
> fulfills the promise of what RESTful services were supposed to be, instead
> of the kludges we’ve come to expect. Look! DELETE actually deletes things!
> POST isn’t just what you use when you need to send more data than a GET
> allows! And HEAD and PUT are actually useful, instead of just being trivia
> to impress your friends at dinner parties — “Oh, did you know that there
> are actually more HTTP commands than just GET and POST?” “Oh, how
> fascinating!”
> […]
> CouchDB doesn’t want to be your database; it wants to be your web site.
>
> [… and after reviewing the drawbacks his conclusion inlcudes:]
> Despite these drawbacks, I still think CouchDB has a lot of potential to
> revolutionize the way people write webapps.
>
> [...]
> In short, CouchDB is an expression of an ideal, a fantastical tale of
> science fiction told by wide-eyed dreamers. And if
> there’s one truth about wide-eyed dreamers, it’s this: with hindsight,
> their predictions either seem delusional, or inevitable.
>
> ========================
>
> The Couch app concept has not been developed for years, but still there
> are some of us that feel like Nolan did over 2 years ago.
> Couch apps is not dead as a vision.
> What I think we need to do is to focus on Nolan’s perspective; the
> simplicity-wins opportunity.
> There are other perspectives that are exiting too, but they dont help to
> define what couch app should be:
>
> Your Smileupps and Hoodie promote background deamons/workers. That is
> irrelevant to this discussion.
> I have been using the same for messaging, image conversion and LinkedIn
> authentication and it would be great to have a standard for node.js based
> listening to _changes. This could be an ecosystem of subscription
> *services* like Mailgun and Postmark. Small teams could make a living out
> of specializing on one cloud service. A service-trigger feature could be
> one of the new features of Couch apps.
> But we need to leave this out of the discussion for now.
>
> We could also take the approach of promoting a new stack, go from LAMP,
> skip MEAN go straight to  C**N, but it is to far-fetched.
>
> I think we need to take the enthusiasm of Nolan as of 2013 and come up
> with some clear design goals and a very limited set of features to add to
> CouchDB ddocs and focus on an in-browser tool (add features to Fauxton)
> that removes the need for new developers to learn git and build tools. That
> would be a great guick hack tool for any developer and a great entry level
> technology for a whole new generation of developers. Who knows what they
> would create before they need to pick their full stack and set up a
> professional tooling and team?
>
> So let me end with a stab at the story again; this time with both docs and
> _changes in mind.
>
> Of course you can used CouchDB in a multi-tier architecture with any stack
> of technologies you like.
> But you can also create and deploy apps and web sites with CouchDB alone.
> A couch app provides a UI for your data and can trigger services that can
> do anything you want with the data.
>
> Johs
>
>
> > On 08 May 2015, at 08:04, Giovanni Lenzi <g....@smileupps.com> wrote:
> >
> > Back on track..
> >
> > the story for couchdb may be to start refering couchdb with a new term
> > like: "web-app-db server", or engine if you prefer.. where its primary
> > meaning is not "web application" and "db server" but instead: "web
> server",
> > "app server" and "db server".. As Paul alread said, to me too this is the
> > power of couchdb.
> >
> > So the new term "web-app-db" may sound weird at first, but I think it's
> > only a matter of telling the users what it is.
> >
> >
> > 2015-05-07 18:31 GMT+02:00 Giovanni Lenzi <g....@smileupps.com>:
> >
> >> 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 <mf...@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 <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
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>
> >>
> >> --
> >> Giovanni Lenzi
> >> www.smileupps.com
> >> Smileupps Couchapps Store
> >>
> >
> >
> >
> > --
> > Giovanni Lenzi
> > www.smileupps.com
> > Smileupps Couchapps Store
>
>


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

Re: the future of couchapp

[Johs Ensby <jo...@b2w.com>]

Giovanni,
I think it is unrealistic to make Couch apps part of the main story of CouchDB
The CouchDB story need to start with DB (ala “data where you need it”)
Then we should be looking for the “one more thing” kind of story (ala Steve Jobs’ nuggets at his keynotes) that top off the story about the DB.

The one-more-thing story would should not diminish are contradict the DB story.

I looked up Nolan Lawson’s (@nolanlawson) enthusiastic blog post from 2013 http://nolanlawson.com/2013/11/15/couchdb-doesnt-want-to-be-your-database-it-wants-to-be-your-web-site/ <http://nolanlawson.com/2013/11/15/couchdb-doesnt-want-to-be-your-database-it-wants-to-be-your-web-site/>
and pull som highlights from that:

========================

He quotes Chris Anderson (@jchris)
Because CouchDB is a web server, you can serve applications directly [to] the browser without any middle tier. When I’m feeling punchy, I like to call the traditional application server stack “extra code to make CouchDB uglier and slower.”

Nolan’s epiphany:
No wait, CouchDB is a miracle
See, here I was, using client-side Javascript to talk to Express to talk to Node to talk to Nano to talk to Couch, and at each step I was converting parameter names from underscores to camel case (or whatever my petty hangups are), all the while introducing bugs as I tried to make each layer fit nicely with the next one. And I had a working web server right in front of me! CouchDB! Why not just call it directly, you fool?! (I shout at myself in hindsight.)
[…]
CouchDB is the web done right
And in fact, CouchDB is better than HTTP, because CouchDB actually fulfills the promise of what RESTful services were supposed to be, instead of the kludges we’ve come to expect. Look! DELETE actually deletes things! POST isn’t just what you use when you need to send more data than a GET allows! And HEAD and PUT are actually useful, instead of just being trivia to impress your friends at dinner parties — “Oh, did you know that there are actually more HTTP commands than just GET and POST?” “Oh, how fascinating!”
[…]
CouchDB doesn’t want to be your database; it wants to be your web site.

[… and after reviewing the drawbacks his conclusion inlcudes:]
Despite these drawbacks, I still think CouchDB has a lot of potential to revolutionize the way people write webapps.

[...]
In short, CouchDB is an expression of an ideal, a fantastical tale of science fiction told by wide-eyed dreamers. And if 
there’s one truth about wide-eyed dreamers, it’s this: with hindsight, their predictions either seem delusional, or inevitable.

========================

The Couch app concept has not been developed for years, but still there are some of us that feel like Nolan did over 2 years ago.
Couch apps is not dead as a vision.
What I think we need to do is to focus on Nolan’s perspective; the simplicity-wins opportunity.
There are other perspectives that are exiting too, but they dont help to define what couch app should be:

Your Smileupps and Hoodie promote background deamons/workers. That is irrelevant to this discussion.
I have been using the same for messaging, image conversion and LinkedIn authentication and it would be great to have a standard for node.js based listening to _changes. This could be an ecosystem of subscription *services* like Mailgun and Postmark. Small teams could make a living out of specializing on one cloud service. A service-trigger feature could be one of the new features of Couch apps.
But we need to leave this out of the discussion for now.

We could also take the approach of promoting a new stack, go from LAMP, skip MEAN go straight to  C**N, but it is to far-fetched.

I think we need to take the enthusiasm of Nolan as of 2013 and come up with some clear design goals and a very limited set of features to add to CouchDB ddocs and focus on an in-browser tool (add features to Fauxton) that removes the need for new developers to learn git and build tools. That would be a great guick hack tool for any developer and a great entry level technology for a whole new generation of developers. Who knows what they would create before they need to pick their full stack and set up a professional tooling and team?

So let me end with a stab at the story again; this time with both docs and _changes in mind.

Of course you can used CouchDB in a multi-tier architecture with any stack of technologies you like.
But you can also create and deploy apps and web sites with CouchDB alone. 
A couch app provides a UI for your data and can trigger services that can do anything you want with the data.

Johs


> On 08 May 2015, at 08:04, Giovanni Lenzi <g....@smileupps.com> wrote:
> 
> Back on track..
> 
> the story for couchdb may be to start refering couchdb with a new term
> like: "web-app-db server", or engine if you prefer.. where its primary
> meaning is not "web application" and "db server" but instead: "web server",
> "app server" and "db server".. As Paul alread said, to me too this is the
> power of couchdb.
> 
> So the new term "web-app-db" may sound weird at first, but I think it's
> only a matter of telling the users what it is.
> 
> 
> 2015-05-07 18:31 GMT+02:00 Giovanni Lenzi <g....@smileupps.com>:
> 
>> 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 <mf...@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 <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
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>> 
>> 
>> --
>> Giovanni Lenzi
>> www.smileupps.com
>> Smileupps Couchapps Store
>> 
> 
> 
> 
> -- 
> Giovanni Lenzi
> www.smileupps.com
> Smileupps Couchapps Store

Re: Re: the future of couchapp

[Giovanni Lenzi <g....@smileupps.com>]

Back on track..

the story for couchdb may be to start refering couchdb with a new term
like: "web-app-db server", or engine if you prefer.. where its primary
meaning is not "web application" and "db server" but instead: "web server",
"app server" and "db server".. As Paul alread said, to me too this is the
power of couchdb.

So the new term "web-app-db" may sound weird at first, but I think it's
only a matter of telling the users what it is.


2015-05-07 18:31 GMT+02:00 Giovanni Lenzi <g....@smileupps.com>:

> 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 <mf...@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 <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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>
>
> --
> Giovanni Lenzi
> www.smileupps.com
> Smileupps Couchapps Store
>



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

Re: Re: the future of couchapp

[Giovanni Lenzi <g....@smileupps.com>]

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 <mf...@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 <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
>>>>>>>>>>>>>
>>>>>>>>>>>>>


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