couchdb-marketing mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: How do CouchApps fit into the CouchDB story? (Was: CouchDB Articles, Pills and Tutorials Ideas)
Date Wed, 06 May 2015 16:16:50 GMT

> On 06 May 2015, at 18:14, Jan Lehnardt <jan@apache.org> wrote:
> 
>> 
>> On 06 May 2015, at 17:57, Giovanni Lenzi <g.lenzi@smileupps.com> wrote:
>> 
>> Given the importance of the topic: the future of couchapp... I'm moving
>> this from the @marketing to the user@ mailing list.
> 
> I’d say this is too early, would prefer we keep this on marketing@ until
> we have the messaging right. Everything else follows from them.

…from that.

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

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


Mime
View raw message