couchdb-marketing mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johs Ensby <j...@b2w.com>
Subject Re: How do CouchApps fit into the CouchDB story? (Was: CouchDB Articles, Pills and Tutorials Ideas)
Date Wed, 06 May 2015 05:10:58 GMT
Giovanni,
on the issue of the death of CouchApps, I think one opportunity is this:
CouchApp is (among all the other things that Jan listed) one or a set of design documents

We have 2 names for the same thing, approximately
My suggestion is to start using ddocs, design docs or design documents and let CouchApp fade
out by itself, no killing needed
Jan,
I like the suggestion to separate CouchApps into a separate project. That should start with
A defined target group
Clear design goals
A rigid plugin architecture 

The idea that I find very powerful is
Let the functionality follow the data
Databases have had stored procedures for ages, but what database provided a methodology for
letting functionality piggyback the data as easily as in CouchDB?
Could there be a sweet spot between “convenience functionality” for advanced developers
and what would be attractive to novice developers and developers looking for a minimalistic
tech stack?

Thanks for listing the pioneers, Jan. Would anyone care to complete the list of people that
took CouchApps to the extreme and would be good candidates for a roundtable on design goals
for its future?
Caolan McMahon of Kanso @caolan <https://twitter.com/caolan>
Dale Harvey of PouchDB @daleharvey <https://twitter.com/daleharvey>
Gregor Martynus of Hoodie @einfachsmart <https://twitter.com/einfachsmart>
Ermouth of Cloudwall @ermouth <https://twitter.com/ermouth> 
Giovanni of Smileupps @smileupps <https://twitter.com/smileupps>

Johs

> On 05 May 2015, at 22:35, Giovanni Lenzi <g.lenzi@smileupps.com> wrote:
> 
> 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
>> 


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