You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Giovanni Lenzi <g....@smileupps.com> on 2015/05/06 17:49:36 UTC
Re: How do CouchApps fit into the CouchDB story? (Was: CouchDB
Articles, Pills and Tutorials Ideas)
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
>>
>
Re: How do CouchApps fit into the CouchDB story? (Was: CouchDB Articles, Pills and Tutorials Ideas)
Posted by Aurélien Bénel <au...@utt.fr>.
> What you all think about it?
> [many users and industries] won't simply understand couchapps removal, leading couchdb to a second-death
Indeed.
Regards,
Aurélien
Re: How do CouchApps fit into the CouchDB story? (Was: CouchDB Articles, Pills and Tutorials Ideas)
Posted by Jan Lehnardt <ja...@apache.org>.
> On 06 May 2015, at 19:29, Samuel Lown <sa...@gmail.com> wrote:
>
> I developed a small mobile couchapp ~4 years ago. The idea was cool, but
> ultimately I felt it required more effort than the benefit for what I
> understood at the time as essentially static file hosting. I'm sure it has
> many more features now.
Nope, it hasn’t changed since :)
>
> CouchApps are a nice add-on and experiment, but with my experience, I'd
> find it difficult to recommend to anyone wanting to build a complex service
> on top of. The logical choice to me is that this is a plugin as opposed to
> a feature.
>
> I'd like to see CouchDB move in the direction Jan proposes: simplicity and
> a clear message of reliable data storage.
Thank you for your vote of confidence!
> Having said that, I'm desperate to see CouchDB 2.0 launched. If deciding
> either means this happens sooner, I'm in favour :-)
Sadly, any discussion here only means CouchDB 2.0 being pushed out further.
I’d suggest for any real work to happen on this to leave post 2.0.
Best
Jan
--
>
> cheers,
> sam
>
>
> On 6 May 2015 at 18:24, Jan Lehnardt <ja...@apache.org> wrote:
>
>>
>>> On 06 May 2015, at 18:18, Alexander Shorin <kx...@gmail.com> wrote:
>>>
>>> On Wed, May 6, 2015 at 6:49 PM, Giovanni Lenzi <g....@smileupps.com>
>> wrote:
>>>> What you all think about it?
>>>
>>> I think we need just clarify what CouchApp is, define it's show cases
>>> and area where they are works perfectly.
>>> First step is to back couchapp.org online (almost done). Then, just
>>> fill it the right content. That will solve any confusions.
>>
>> Before we fix anything, we need to understand how to fix it. To understand
>> how to fix it we need to understand what we do. To understand what we do,
>> we need to understand why we do it. — Hence, we first need to find a “The
>> Why of CouchDB” story that reflects our intentions before any of the other
>> decisions can happen. That’s what my original message is about.
>>
>>
>>> I'm -1 for removal CouchApps as a since it's not possible as CouchApps
>>> are not a some entity, but a way of organizing design documents in
>>> order to solve some specific problem.
>>
>> The problem is, as outlined in my emails on marketing@ that I linked
>> earlier
>> that “CouchApp” means at least eight different things to different groups
>> of
>> people. That is terribly confusing and makes people new to CouchDB leave us
>> in spades because it is just too complicated.
>>
>> I never meant for the actual technical features in CouchDB to be removed
>> and
>> I never said so.
>>
>>> We just need to find a sweet spot, a right vector for their future since
>> as
>>> for now I feel CouchApp as a technology is just lost in space.
>>
>> Exactly, and its harming CouchDB.
>>
>> To get this rolling, we need to understand what we do and why we do it.
>> Then
>> we can decide if and how “CouchApp” in whatever form fits into this.
>>
>> Best
>> Jan
>> --
>>
>>
>
>
> --
> www.samlown.com
> www.cabify.com
> www.autofiscal.com
--
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/
Re: How do CouchApps fit into the CouchDB story? (Was: CouchDB
Articles, Pills and Tutorials Ideas)
Posted by Samuel Lown <sa...@gmail.com>.
I developed a small mobile couchapp ~4 years ago. The idea was cool, but
ultimately I felt it required more effort than the benefit for what I
understood at the time as essentially static file hosting. I'm sure it has
many more features now.
CouchApps are a nice add-on and experiment, but with my experience, I'd
find it difficult to recommend to anyone wanting to build a complex service
on top of. The logical choice to me is that this is a plugin as opposed to
a feature.
I'd like to see CouchDB move in the direction Jan proposes: simplicity and
a clear message of reliable data storage.
Having said that, I'm desperate to see CouchDB 2.0 launched. If deciding
either means this happens sooner, I'm in favour :-)
cheers,
sam
On 6 May 2015 at 18:24, Jan Lehnardt <ja...@apache.org> wrote:
>
> > On 06 May 2015, at 18:18, Alexander Shorin <kx...@gmail.com> wrote:
> >
> > On Wed, May 6, 2015 at 6:49 PM, Giovanni Lenzi <g....@smileupps.com>
> wrote:
> >> What you all think about it?
> >
> > I think we need just clarify what CouchApp is, define it's show cases
> > and area where they are works perfectly.
> > First step is to back couchapp.org online (almost done). Then, just
> > fill it the right content. That will solve any confusions.
>
> Before we fix anything, we need to understand how to fix it. To understand
> how to fix it we need to understand what we do. To understand what we do,
> we need to understand why we do it. — Hence, we first need to find a “The
> Why of CouchDB” story that reflects our intentions before any of the other
> decisions can happen. That’s what my original message is about.
>
>
> > I'm -1 for removal CouchApps as a since it's not possible as CouchApps
> > are not a some entity, but a way of organizing design documents in
> > order to solve some specific problem.
>
> The problem is, as outlined in my emails on marketing@ that I linked
> earlier
> that “CouchApp” means at least eight different things to different groups
> of
> people. That is terribly confusing and makes people new to CouchDB leave us
> in spades because it is just too complicated.
>
> I never meant for the actual technical features in CouchDB to be removed
> and
> I never said so.
>
> > We just need to find a sweet spot, a right vector for their future since
> as
> > for now I feel CouchApp as a technology is just lost in space.
>
> Exactly, and its harming CouchDB.
>
> To get this rolling, we need to understand what we do and why we do it.
> Then
> we can decide if and how “CouchApp” in whatever form fits into this.
>
> Best
> Jan
> --
>
>
--
www.samlown.com
www.cabify.com
www.autofiscal.com
Re: How do CouchApps fit into the CouchDB story? (Was: CouchDB Articles, Pills and Tutorials Ideas)
Posted by Paul Okstad <po...@gmail.com>.
> On May 6, 2015, at 9:59 AM, Giovanni Lenzi <g....@smileupps.com> wrote:
>
> Furthermore, as CouchDB Hosting provider, I can say Couchapps are
> extensively used by users.. so the story could be instead to give them
> more visibility, by advocating them and clarifying what they can and cannot
> do.. with facts, tutorials, examples and benchmarks.
The original defacto CouchApp guide for me was the CouchDB: Definitive Guide (http://guide.couchdb.org). Sadly, this reference is extremely old and out of date. One of the best things someone could do to help the CouchDB community would be to either update this book or start it’s spiritual replacement.
--
Paul Okstad
http://pokstad.com <http://pokstad.com/>
Re: How do CouchApps fit into the CouchDB story? (Was: CouchDB
Articles, Pills and Tutorials Ideas)
Posted by Giovanni P <fi...@gmail.com>.
As a novice, outside user and someone who hasn't followed the CouchDB
history from the beggining, I always imagined that the idea of having
complete apps running on top of CouchDB was something that emerged directly
and straightforwardly from the everything-is-HTTP paradigm. It feels right
to let people use the REST infrastructure that is already working to output
other things instead of just default JSON, and you already have a nice
solution: the limited-access Javascript engine. Again, I think that when
you developed this, you were just following the logic: what is the next
step after having a HTTP-only document database?
The CouchApp branch merges with the replication branch in the concept of
entire apps being cloned (enabling personal webapps for all things) with
one _replicate command.
The bigger problem, as I see, besides the naming, which is really
confusing, is the work it takes to create a simple index for non-CouchApps.
If you're writing a CouchApp then you're good with the CLI tools, the
directory structure, the handwritten indexes and so on, but if you're
writing a regular 3-tier application, having to work with directories and
third-party tools is not great.
Also, I agree with everything Paul Okstad is saying.
On Wed, May 6, 2015 at 2:44 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
> > On 06 May 2015, at 19:39, Giovanni Lenzi <g....@smileupps.com> wrote:
> >
> > 2015-05-06 19:20 GMT+02:00 Jan Lehnardt <ja...@apache.org>:
> >
> >>
> >>> On 06 May 2015, at 18:59, Giovanni Lenzi <g....@smileupps.com>
> wrote:
> >>>
> >>>> To get this rolling, we need to understand what we do and why we do
> it.
> >>>
> >>> Considered couchapps new amazing features(
> >>> http://markmail.org/message/poxvkumqqi4fugeo and
> >>> http://markmail.org/message/rfbczt46ytlldjtj) and ermouth proposal
> for a
> >>> platform-indipendent and browser-only couchapp development environment(
> >>> http://markmail.org/message/rckxmbx3tl7nags5), Couchapps can really
> have
> >>> big impact on CouchDB adoption-rate... so I think they are a big plus
> for
> >>> the project.
> >>
> >> That is fantastic! Again, I’m not advocating to remove any of the tech
> >> that makes this happen.
> >>
> >>> Furthermore, as CouchDB Hosting provider, I can say Couchapps are
> >>> extensively used by users..so the story could be instead to give them
> >>> more visibility, by advocating them and clarifying what they can and
> >> cannot
> >>> do.. with facts, tutorials, examples and benchmarks.
> >>
> >> These are action items. Not a story. Let’s work on the story on
> marketing@
> >> ,
> >> before we agree on action items.
> >>
> >>
> > The story could be: "CouchDB, the only web, app and db server cake" ,
> where
> > the user can choose to eat only one slice of the cake or eat it all.. :))
> >
> > This includes all CouchDB features, withouth sacrificing netiher
> couchapps,
> > neither core functionalities
> >
>
> Be sure to bring this up on marketing@! :)
>
> Best
> Jan
> --
>
> >
> >
> >> Best
> >> Jan
> >> --
> >> “It is difficult to get a man to understand something,
> >> when his salary depends upon his not understanding it.”
> >> — Upton Sinclair
> >>
> >>
> >>
> >>
> >>>
> >>>
> >>>
> >>> 2015-05-06 18:24 GMT+02:00 Jan Lehnardt <ja...@apache.org>:
> >>>
> >>>>
> >>>>> On 06 May 2015, at 18:18, Alexander Shorin <kx...@gmail.com> wrote:
> >>>>>
> >>>>> On Wed, May 6, 2015 at 6:49 PM, Giovanni Lenzi <
> g.lenzi@smileupps.com>
> >>>> wrote:
> >>>>>> What you all think about it?
> >>>>>
> >>>>> I think we need just clarify what CouchApp is, define it's show cases
> >>>>> and area where they are works perfectly.
> >>>>> First step is to back couchapp.org online (almost done). Then, just
> >>>>> fill it the right content. That will solve any confusions.
> >>>>
> >>>> Before we fix anything, we need to understand how to fix it. To
> >> understand
> >>>> how to fix it we need to understand what we do. To understand what we
> >> do,
> >>>> we need to understand why we do it. — Hence, we first need to find a
> >> “The
> >>>> Why of CouchDB” story that reflects our intentions before any of the
> >> other
> >>>> decisions can happen. That’s what my original message is about.
> >>>>
> >>>>
> >>>>> I'm -1 for removal CouchApps as a since it's not possible as
> CouchApps
> >>>>> are not a some entity, but a way of organizing design documents in
> >>>>> order to solve some specific problem.
> >>>>
> >>>> The problem is, as outlined in my emails on marketing@ that I linked
> >>>> earlier
> >>>> that “CouchApp” means at least eight different things to different
> >> groups
> >>>> of
> >>>> people. That is terribly confusing and makes people new to CouchDB
> >> leave us
> >>>> in spades because it is just too complicated.
> >>>>
> >>>> I never meant for the actual technical features in CouchDB to be
> removed
> >>>> and
> >>>> I never said so.
> >>>>
> >>>>> We just need to find a sweet spot, a right vector for their future
> >> since
> >>>> as
> >>>>> for now I feel CouchApp as a technology is just lost in space.
> >>>>
> >>>> Exactly, and its harming CouchDB.
> >>>>
> >>>> To get this rolling, we need to understand what we do and why we do
> it.
> >>>> Then
> >>>> we can decide if and how “CouchApp” in whatever form fits into this.
> >>>>
> >>>> Best
> >>>> Jan
> >>>> --
>
> --
> Professional Support for Apache CouchDB:
> http://www.neighbourhood.ie/couchdb-support/
>
>
Re: How do CouchApps fit into the CouchDB story? (Was: CouchDB Articles, Pills and Tutorials Ideas)
Posted by Jan Lehnardt <ja...@apache.org>.
> On 06 May 2015, at 19:39, Giovanni Lenzi <g....@smileupps.com> wrote:
>
> 2015-05-06 19:20 GMT+02:00 Jan Lehnardt <ja...@apache.org>:
>
>>
>>> On 06 May 2015, at 18:59, Giovanni Lenzi <g....@smileupps.com> wrote:
>>>
>>>> To get this rolling, we need to understand what we do and why we do it.
>>>
>>> Considered couchapps new amazing features(
>>> http://markmail.org/message/poxvkumqqi4fugeo and
>>> http://markmail.org/message/rfbczt46ytlldjtj) and ermouth proposal for a
>>> platform-indipendent and browser-only couchapp development environment(
>>> http://markmail.org/message/rckxmbx3tl7nags5), Couchapps can really have
>>> big impact on CouchDB adoption-rate... so I think they are a big plus for
>>> the project.
>>
>> That is fantastic! Again, I’m not advocating to remove any of the tech
>> that makes this happen.
>>
>>> Furthermore, as CouchDB Hosting provider, I can say Couchapps are
>>> extensively used by users..so the story could be instead to give them
>>> more visibility, by advocating them and clarifying what they can and
>> cannot
>>> do.. with facts, tutorials, examples and benchmarks.
>>
>> These are action items. Not a story. Let’s work on the story on marketing@
>> ,
>> before we agree on action items.
>>
>>
> The story could be: "CouchDB, the only web, app and db server cake" , where
> the user can choose to eat only one slice of the cake or eat it all.. :))
>
> This includes all CouchDB features, withouth sacrificing netiher couchapps,
> neither core functionalities
>
Be sure to bring this up on marketing@! :)
Best
Jan
--
>
>
>> Best
>> Jan
>> --
>> “It is difficult to get a man to understand something,
>> when his salary depends upon his not understanding it.”
>> — Upton Sinclair
>>
>>
>>
>>
>>>
>>>
>>>
>>> 2015-05-06 18:24 GMT+02:00 Jan Lehnardt <ja...@apache.org>:
>>>
>>>>
>>>>> On 06 May 2015, at 18:18, Alexander Shorin <kx...@gmail.com> wrote:
>>>>>
>>>>> On Wed, May 6, 2015 at 6:49 PM, Giovanni Lenzi <g....@smileupps.com>
>>>> wrote:
>>>>>> What you all think about it?
>>>>>
>>>>> I think we need just clarify what CouchApp is, define it's show cases
>>>>> and area where they are works perfectly.
>>>>> First step is to back couchapp.org online (almost done). Then, just
>>>>> fill it the right content. That will solve any confusions.
>>>>
>>>> Before we fix anything, we need to understand how to fix it. To
>> understand
>>>> how to fix it we need to understand what we do. To understand what we
>> do,
>>>> we need to understand why we do it. — Hence, we first need to find a
>> “The
>>>> Why of CouchDB” story that reflects our intentions before any of the
>> other
>>>> decisions can happen. That’s what my original message is about.
>>>>
>>>>
>>>>> I'm -1 for removal CouchApps as a since it's not possible as CouchApps
>>>>> are not a some entity, but a way of organizing design documents in
>>>>> order to solve some specific problem.
>>>>
>>>> The problem is, as outlined in my emails on marketing@ that I linked
>>>> earlier
>>>> that “CouchApp” means at least eight different things to different
>> groups
>>>> of
>>>> people. That is terribly confusing and makes people new to CouchDB
>> leave us
>>>> in spades because it is just too complicated.
>>>>
>>>> I never meant for the actual technical features in CouchDB to be removed
>>>> and
>>>> I never said so.
>>>>
>>>>> We just need to find a sweet spot, a right vector for their future
>> since
>>>> as
>>>>> for now I feel CouchApp as a technology is just lost in space.
>>>>
>>>> Exactly, and its harming CouchDB.
>>>>
>>>> To get this rolling, we need to understand what we do and why we do it.
>>>> Then
>>>> we can decide if and how “CouchApp” in whatever form fits into this.
>>>>
>>>> Best
>>>> Jan
>>>> --
--
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/
Re: How do CouchApps fit into the CouchDB story? (Was: CouchDB
Articles, Pills and Tutorials Ideas)
Posted by Giovanni Lenzi <g....@smileupps.com>.
2015-05-06 19:20 GMT+02:00 Jan Lehnardt <ja...@apache.org>:
>
> > On 06 May 2015, at 18:59, Giovanni Lenzi <g....@smileupps.com> wrote:
> >
> >> To get this rolling, we need to understand what we do and why we do it.
> >
> > Considered couchapps new amazing features(
> > http://markmail.org/message/poxvkumqqi4fugeo and
> > http://markmail.org/message/rfbczt46ytlldjtj) and ermouth proposal for a
> > platform-indipendent and browser-only couchapp development environment(
> > http://markmail.org/message/rckxmbx3tl7nags5), Couchapps can really have
> > big impact on CouchDB adoption-rate... so I think they are a big plus for
> > the project.
>
> That is fantastic! Again, I’m not advocating to remove any of the tech
> that makes this happen.
>
> > Furthermore, as CouchDB Hosting provider, I can say Couchapps are
> > extensively used by users..so the story could be instead to give them
> > more visibility, by advocating them and clarifying what they can and
> cannot
> > do.. with facts, tutorials, examples and benchmarks.
>
> These are action items. Not a story. Let’s work on the story on marketing@
> ,
> before we agree on action items.
>
>
The story could be: "CouchDB, the only web, app and db server cake" , where
the user can choose to eat only one slice of the cake or eat it all.. :))
This includes all CouchDB features, withouth sacrificing netiher couchapps,
neither core functionalities
> Best
> Jan
> --
> “It is difficult to get a man to understand something,
> when his salary depends upon his not understanding it.”
> — Upton Sinclair
>
>
>
>
> >
> >
> >
> > 2015-05-06 18:24 GMT+02:00 Jan Lehnardt <ja...@apache.org>:
> >
> >>
> >>> On 06 May 2015, at 18:18, Alexander Shorin <kx...@gmail.com> wrote:
> >>>
> >>> On Wed, May 6, 2015 at 6:49 PM, Giovanni Lenzi <g....@smileupps.com>
> >> wrote:
> >>>> What you all think about it?
> >>>
> >>> I think we need just clarify what CouchApp is, define it's show cases
> >>> and area where they are works perfectly.
> >>> First step is to back couchapp.org online (almost done). Then, just
> >>> fill it the right content. That will solve any confusions.
> >>
> >> Before we fix anything, we need to understand how to fix it. To
> understand
> >> how to fix it we need to understand what we do. To understand what we
> do,
> >> we need to understand why we do it. — Hence, we first need to find a
> “The
> >> Why of CouchDB” story that reflects our intentions before any of the
> other
> >> decisions can happen. That’s what my original message is about.
> >>
> >>
> >>> I'm -1 for removal CouchApps as a since it's not possible as CouchApps
> >>> are not a some entity, but a way of organizing design documents in
> >>> order to solve some specific problem.
> >>
> >> The problem is, as outlined in my emails on marketing@ that I linked
> >> earlier
> >> that “CouchApp” means at least eight different things to different
> groups
> >> of
> >> people. That is terribly confusing and makes people new to CouchDB
> leave us
> >> in spades because it is just too complicated.
> >>
> >> I never meant for the actual technical features in CouchDB to be removed
> >> and
> >> I never said so.
> >>
> >>> We just need to find a sweet spot, a right vector for their future
> since
> >> as
> >>> for now I feel CouchApp as a technology is just lost in space.
> >>
> >> Exactly, and its harming CouchDB.
> >>
> >> To get this rolling, we need to understand what we do and why we do it.
> >> Then
> >> we can decide if and how “CouchApp” in whatever form fits into this.
> >>
> >> Best
> >> Jan
> >> --
> >>
>
>
Re: How do CouchApps fit into the CouchDB story? (Was: CouchDB Articles, Pills and Tutorials Ideas)
Posted by Jan Lehnardt <ja...@apache.org>.
> On 06 May 2015, at 18:59, Giovanni Lenzi <g....@smileupps.com> wrote:
>
>> To get this rolling, we need to understand what we do and why we do it.
>
> Considered couchapps new amazing features(
> http://markmail.org/message/poxvkumqqi4fugeo and
> http://markmail.org/message/rfbczt46ytlldjtj) and ermouth proposal for a
> platform-indipendent and browser-only couchapp development environment(
> http://markmail.org/message/rckxmbx3tl7nags5), Couchapps can really have
> big impact on CouchDB adoption-rate... so I think they are a big plus for
> the project.
That is fantastic! Again, I’m not advocating to remove any of the tech
that makes this happen.
> Furthermore, as CouchDB Hosting provider, I can say Couchapps are
> extensively used by users..so the story could be instead to give them
> more visibility, by advocating them and clarifying what they can and cannot
> do.. with facts, tutorials, examples and benchmarks.
These are action items. Not a story. Let’s work on the story on marketing@,
before we agree on action items.
Best
Jan
--
“It is difficult to get a man to understand something,
when his salary depends upon his not understanding it.”
— Upton Sinclair
>
>
>
> 2015-05-06 18:24 GMT+02:00 Jan Lehnardt <ja...@apache.org>:
>
>>
>>> On 06 May 2015, at 18:18, Alexander Shorin <kx...@gmail.com> wrote:
>>>
>>> On Wed, May 6, 2015 at 6:49 PM, Giovanni Lenzi <g....@smileupps.com>
>> wrote:
>>>> What you all think about it?
>>>
>>> I think we need just clarify what CouchApp is, define it's show cases
>>> and area where they are works perfectly.
>>> First step is to back couchapp.org online (almost done). Then, just
>>> fill it the right content. That will solve any confusions.
>>
>> Before we fix anything, we need to understand how to fix it. To understand
>> how to fix it we need to understand what we do. To understand what we do,
>> we need to understand why we do it. — Hence, we first need to find a “The
>> Why of CouchDB” story that reflects our intentions before any of the other
>> decisions can happen. That’s what my original message is about.
>>
>>
>>> I'm -1 for removal CouchApps as a since it's not possible as CouchApps
>>> are not a some entity, but a way of organizing design documents in
>>> order to solve some specific problem.
>>
>> The problem is, as outlined in my emails on marketing@ that I linked
>> earlier
>> that “CouchApp” means at least eight different things to different groups
>> of
>> people. That is terribly confusing and makes people new to CouchDB leave us
>> in spades because it is just too complicated.
>>
>> I never meant for the actual technical features in CouchDB to be removed
>> and
>> I never said so.
>>
>>> We just need to find a sweet spot, a right vector for their future since
>> as
>>> for now I feel CouchApp as a technology is just lost in space.
>>
>> Exactly, and its harming CouchDB.
>>
>> To get this rolling, we need to understand what we do and why we do it.
>> Then
>> we can decide if and how “CouchApp” in whatever form fits into this.
>>
>> Best
>> Jan
>> --
>>
Re: How do CouchApps fit into the CouchDB story? (Was: CouchDB
Articles, Pills and Tutorials Ideas)
Posted by Giovanni Lenzi <g....@smileupps.com>.
> To get this rolling, we need to understand what we do and why we do it.
Considered couchapps new amazing features(
http://markmail.org/message/poxvkumqqi4fugeo and
http://markmail.org/message/rfbczt46ytlldjtj) and ermouth proposal for a
platform-indipendent and browser-only couchapp development environment(
http://markmail.org/message/rckxmbx3tl7nags5), Couchapps can really have
big impact on CouchDB adoption-rate... so I think they are a big plus for
the project.
Furthermore, as CouchDB Hosting provider, I can say Couchapps are
extensively used by users.. so the story could be instead to give them
more visibility, by advocating them and clarifying what they can and cannot
do.. with facts, tutorials, examples and benchmarks.
2015-05-06 18:24 GMT+02:00 Jan Lehnardt <ja...@apache.org>:
>
> > On 06 May 2015, at 18:18, Alexander Shorin <kx...@gmail.com> wrote:
> >
> > On Wed, May 6, 2015 at 6:49 PM, Giovanni Lenzi <g....@smileupps.com>
> wrote:
> >> What you all think about it?
> >
> > I think we need just clarify what CouchApp is, define it's show cases
> > and area where they are works perfectly.
> > First step is to back couchapp.org online (almost done). Then, just
> > fill it the right content. That will solve any confusions.
>
> Before we fix anything, we need to understand how to fix it. To understand
> how to fix it we need to understand what we do. To understand what we do,
> we need to understand why we do it. — Hence, we first need to find a “The
> Why of CouchDB” story that reflects our intentions before any of the other
> decisions can happen. That’s what my original message is about.
>
>
> > I'm -1 for removal CouchApps as a since it's not possible as CouchApps
> > are not a some entity, but a way of organizing design documents in
> > order to solve some specific problem.
>
> The problem is, as outlined in my emails on marketing@ that I linked
> earlier
> that “CouchApp” means at least eight different things to different groups
> of
> people. That is terribly confusing and makes people new to CouchDB leave us
> in spades because it is just too complicated.
>
> I never meant for the actual technical features in CouchDB to be removed
> and
> I never said so.
>
> > We just need to find a sweet spot, a right vector for their future since
> as
> > for now I feel CouchApp as a technology is just lost in space.
>
> Exactly, and its harming CouchDB.
>
> To get this rolling, we need to understand what we do and why we do it.
> Then
> we can decide if and how “CouchApp” in whatever form fits into this.
>
> Best
> Jan
> --
>
>
Re: How do CouchApps fit into the CouchDB story? (Was: CouchDB Articles, Pills and Tutorials Ideas)
Posted by Jan Lehnardt <ja...@apache.org>.
> On 06 May 2015, at 18:18, Alexander Shorin <kx...@gmail.com> wrote:
>
> On Wed, May 6, 2015 at 6:49 PM, Giovanni Lenzi <g....@smileupps.com> wrote:
>> What you all think about it?
>
> I think we need just clarify what CouchApp is, define it's show cases
> and area where they are works perfectly.
> First step is to back couchapp.org online (almost done). Then, just
> fill it the right content. That will solve any confusions.
Before we fix anything, we need to understand how to fix it. To understand
how to fix it we need to understand what we do. To understand what we do,
we need to understand why we do it. — Hence, we first need to find a “The
Why of CouchDB” story that reflects our intentions before any of the other
decisions can happen. That’s what my original message is about.
> I'm -1 for removal CouchApps as a since it's not possible as CouchApps
> are not a some entity, but a way of organizing design documents in
> order to solve some specific problem.
The problem is, as outlined in my emails on marketing@ that I linked earlier
that “CouchApp” means at least eight different things to different groups of
people. That is terribly confusing and makes people new to CouchDB leave us
in spades because it is just too complicated.
I never meant for the actual technical features in CouchDB to be removed and
I never said so.
> We just need to find a sweet spot, a right vector for their future since as
> for now I feel CouchApp as a technology is just lost in space.
Exactly, and its harming CouchDB.
To get this rolling, we need to understand what we do and why we do it. Then
we can decide if and how “CouchApp” in whatever form fits into this.
Best
Jan
--
Re: How do CouchApps fit into the CouchDB story? (Was: CouchDB
Articles, Pills and Tutorials Ideas)
Posted by Alexander Shorin <kx...@gmail.com>.
On Wed, May 6, 2015 at 6:49 PM, Giovanni Lenzi <g....@smileupps.com> wrote:
> What you all think about it?
I think we need just clarify what CouchApp is, define it's show cases
and area where they are works perfectly.
First step is to back couchapp.org online (almost done). Then, just
fill it the right content. That will solve any confusions.
I'm -1 for removal CouchApps as a since it's not possible as CouchApps
are not a some entity, but a way of organizing design documents in
order to solve some specific problem. We just need to find a sweet
spot, a right vector for their future since as for now I feel CouchApp
as a technology is just lost in space.
--
,,,^..^,,,
Re: How do CouchApps fit into the CouchDB story? (Was: CouchDB Articles, Pills and Tutorials Ideas)
Posted by Aurélien Bénel <au...@utt.fr>.
Hi CouchDB folks,
In a controversy, there are always good and bad things happening.
I would recommend getting rid of personal anger, and focus on CouchDB fantastic features that emerge from the discussion.
> When I think of CouchDB, I think about how it is “of the web” and has these brilliant design document strategies that FORCE the user to efficiently create side-effect free transformations of documents and views that work nicely with proxies, etc. Before CouchDB, I never cared about the etag and didn’t use all of the HTTP methods and return codes properly. I didn’t think REST-fully.
> Having a system that structures your code, prevents you from doing stupid non-scaleable things, and forces you to think REST-fully is superior to just winging it free-form in an anything-goes programming environment (unless you’re awesome, but most of us are not). I would like to see more features that FORCE web developers to create a proper RESTful webapp and reinforce the original concept that CouchDB is a pure phenomenon of the web.
I would second that.
When I first adopted CouchDB in 2010, this was just to implement a REST service, and I was amazed how coherent this was (with all headers, status codes and even MapReduce as a way to get derived resources to reduce latency).
Shows and lists helped me understand the distinction made by HTTP specification between a "resource" and a "representation", and therefore the (partial) obsolescence of 3-tier architectures when you have HTTP services (and hence the need to provide a default HTML+JS user interface along with your JSON API).
By the way it would be great if it was easier to have the same URI for a document and a show (or a view and a list), since it is the same abstract "resource", and then to route the request towards a different script according to the `Accept` header.
For all these reasons, I have used CouchDB in every research software I had to implement since. And I adopted CouchDB as THE ultimate tool to teach REST services to my students for several years.
Long live CouchDB,
Aurélien
Re: How do CouchApps fit into the CouchDB story? (Was:
CouchDB Articles, Pills and Tutorials Ideas)
Posted by Miles Fidelman <mf...@meetinghouse.net>.
Paul just said it so much better than I did.
Miles
Paul Okstad wrote:
>> On May 6, 2015, at 8:49 AM, Giovanni Lenzi <g....@smileupps.com> wrote:
>>
>> Jan: wants to remove Couchapp name and design doc functions because it
>> finds them to be source of confusion
> I understand there has been some hinting that show/list functions will be deprecated, is this what you are referring to?
>
> To me, a CouchApp is not a script that conveniently loads all of your code into CouchDB, it is the notion that all you need to run your web app is a CouchDB instance. It is the concept of having everything you need in the design documents and server configuration.
>
> Personally, one of the original reasons for me being attracted to CouchDB was the ability to implement nearly everything a web server can do in the design docs. Show and list functions seemed like a brilliant idea, but in practice they were hard to write because of the default Javascript environment. Also, others have complained of the performance. I wish there was a way to improve that design, not remove it.
>
> Recently I have been implementing more and more functionality in Go/Python/Node and using a reverse proxy to expose the API of Couch that I like. I feel this is not good for CouchDB. If all I’m using Couch for is a simple document database, there are plenty of faster alternatives out there. When I think of CouchDB, I think about how it is “of the web” and has these brilliant design document strategies that FORCE the user to efficiently create side-effect free transformations of documents and views that work nicely with proxies, etc. Before CouchDB, I never cared about the etag and didn’t use all of the HTTP methods and return codes properly. I didn’t think REST-fully.
>
> Having a system that structures your code, prevents you from doing stupid non-scaleable things, and forces you to think REST-fully is superior to just winging it free-form in an anything-goes programming environment (unless you’re awesome, but most of us are not). I would like to see more features that FORCE web developers to create a proper RESTful webapp and reinforce the original concept that CouchDB is a pure phenomenon of the web. Or maybe I’m completely off. That being said: “LOVE LIVE COUCHAPPS!!!"
>
--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
Re: How do CouchApps fit into the CouchDB story? (Was: CouchDB Articles, Pills and Tutorials Ideas)
Posted by Paul Okstad <po...@gmail.com>.
> On May 6, 2015, at 8:49 AM, Giovanni Lenzi <g....@smileupps.com> wrote:
>
> Jan: wants to remove Couchapp name and design doc functions because it
> finds them to be source of confusion
I understand there has been some hinting that show/list functions will be deprecated, is this what you are referring to?
To me, a CouchApp is not a script that conveniently loads all of your code into CouchDB, it is the notion that all you need to run your web app is a CouchDB instance. It is the concept of having everything you need in the design documents and server configuration.
Personally, one of the original reasons for me being attracted to CouchDB was the ability to implement nearly everything a web server can do in the design docs. Show and list functions seemed like a brilliant idea, but in practice they were hard to write because of the default Javascript environment. Also, others have complained of the performance. I wish there was a way to improve that design, not remove it.
Recently I have been implementing more and more functionality in Go/Python/Node and using a reverse proxy to expose the API of Couch that I like. I feel this is not good for CouchDB. If all I’m using Couch for is a simple document database, there are plenty of faster alternatives out there. When I think of CouchDB, I think about how it is “of the web” and has these brilliant design document strategies that FORCE the user to efficiently create side-effect free transformations of documents and views that work nicely with proxies, etc. Before CouchDB, I never cared about the etag and didn’t use all of the HTTP methods and return codes properly. I didn’t think REST-fully.
Having a system that structures your code, prevents you from doing stupid non-scaleable things, and forces you to think REST-fully is superior to just winging it free-form in an anything-goes programming environment (unless you’re awesome, but most of us are not). I would like to see more features that FORCE web developers to create a proper RESTful webapp and reinforce the original concept that CouchDB is a pure phenomenon of the web. Or maybe I’m completely off. That being said: “LOVE LIVE COUCHAPPS!!!"
--
Paul Okstad
http://pokstad.com