couchdb-marketing mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giovanni Lenzi <g.le...@smileupps.com>
Subject Re: How do CouchApps fit into the CouchDB story? (Was: CouchDB Articles, Pills and Tutorials Ideas)
Date Wed, 06 May 2015 07:05:04 GMT
I agree John, with all you said.
- ddocs term is probably less confusing
- fadeout of the word "couchapp" withouth killing
- a separate project if it can effectively add more value to web-app
development

2015-05-06 7:10 GMT+02:00 Johs Ensby <johs@b2w.com>:

> 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