Mailing-List: contact marketing-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: marketing@couchdb.apache.org
Received-SPF: pass (athena.apache.org: message received from 54.191.145.13
 which is an MX secondary for marketing@couchdb.apache.org)
MIME-Version: 1.0
In-Reply-To: <D328F540-26C0-468C-AE43-1489818B414A@apache.org>
References: 
 <CAPMhwa5R6CdeQP-m_FHfqYsJ4NDwLYiePuwrsi2bRfzifncRpw@mail.gmail.com>
	<CAHw0XrtCxKWzM5x9Q2XjqxV3HOPLKCyOuTVOpMOeJKobJCzs5g@mail.gmail.com>
	<CAPMhwa7KTf4QTYm5HKyG2TxAzYPJ4a5CxAg90v8A26gY=W7poQ@mail.gmail.com>
	<CAHw0Xrt=1zvX9ud_Dezmks6jP10kPWMp08qXqO2ohO9yWCi2pw@mail.gmail.com>
	<CAPMhwa4XzFmPEdWRTdrtQW4x4thXcsCMe-OrJyA81OfL8DMTEQ@mail.gmail.com>
	<CAHw0XrtWiqQbQdaYoGGrjK2kGthJHeqTKg6K-EzzqfOe0rVycg@mail.gmail.com>
	<33BD4D82-787C-48D5-B963-FEEA4C0913CB@apache.org>
	<CADA9kr_7X6ha_hK3qb7N4FLDKeXCUQ7kDnYxN86Vzs_mRLKeCg@mail.gmail.com>
	<4209351E-F51E-4DB5-8A5F-8AB53DA21877@apache.org>
	<CAPMhwa4SeOJyj7618u_MvG1CredCm2J3a5p8pL9Lo7nCRjk3dQ@mail.gmail.com>
	<47CA7E1D-AC9D-42C3-9188-778265347F10@apache.org>
	<CAPMhwa7gjAXhGqY1S-snes7O_dMMWwoo0HiG-22qpbUus=zn_w@mail.gmail.com>
	<D328F540-26C0-468C-AE43-1489818B414A@apache.org>
Date: Tue, 5 May 2015 14:18:40 +0200
Message-ID: 
 <CAPMhwa5LVA4X1yV+vOGDitnmBe4Nn+ErK5KpZBCqZhY=Qm41QA@mail.gmail.com>
Subject: Re: SmileUpps Features (Was: How do CouchApps fit into the CouchDB
 story? (Was: CouchDB Articles, Pills and Tutorials Ideas))
From: Giovanni Lenzi <g.lenzi@smileupps.com>
To: marketing@couchdb.apache.org
Content-Type: multipart/alternative; boundary=90e6ba1efd82c47e0a051554ad78

--90e6ba1efd82c47e0a051554ad78
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

> That looks like you are using a changes filter. A client has to opt into
that. what if a client calls changes without the filter?

Request is denied if the changes filter does not receive as query
parameter(or in path) the same userid which is authenticated (can be done
comparing req.userCtx.name or anything inside req.userCtx.roles)

So:
- changes for non authenticated users is denied
- changes with incorrect user id are denied
- to optimize performance, changes request with a since query parameter too
old, are rejected... and list-view has to be used.


2015-05-05 13:42 GMT+02:00 Jan Lehnardt <jan@apache.org>:

>
> > On 05 May 2015, at 13:17, Giovanni Lenzi <g.lenzi@smileupps.com> wrote:
> >
> >> How do you do per-doc or per-attachment ACL? Those are not core CouchD=
B
> > features.
> >
> > per-doc:
> > - read : https://www.smileupps.com/couchapp-tutorial-chatty-read-api
>
> That looks like you are using a changes filter. A client has to opt into
> that. what if a client calls changes without the filter?
>
> > - write: https://www.smileupps.com/couchapp-tutorial-chatty-write-api
> >
> > per-attachments: a tutorial will come.. however
> > - write: same method used in
> > https://www.smileupps.com/couchapp-tutorial-chatty-write-api
> > - reads: through unguessable ids, which is industry common practice
> >
> > all of the above can be seriously enhanced with filtered changes and so=
me
> > minor improvements to rewriting engine module.
> >
> >
> >
> > 2015-05-05 13:01 GMT+02:00 Jan Lehnardt <jan@apache.org>:
> >
> >>
> >>> On 05 May 2015, at 12:54, Giovanni Lenzi <g.lenzi@smileupps.com>
> wrote:
> >>>
> >>> I think it's a timing problem.. probably Couchapps were simply not
> mature
> >>> enough some years ago.. but nowadays their potential has increased a
> lot,
> >>> under every aspect.
> >>>
> >>> IMHO they are even one of the best way to implement granular
> server-side
> >>> security.
> >>>
> >>> - security: server-side read and write ACLS are a reality(
> >>> https://www.smileupps.com/couchapp-tutorial-chatty)
> >>>  - filtered changes from RCouch will improve security even further
> >>>  - probably, some minor tweaks to the rewriting engine module can
> easily
> >>> add ACL at view level, so improving performance on #3
> >>>  - ACL for _attachments is already possible. We have a tutorial
> >> scheduled
> >>> on that
> >>
> >> How do you do per-doc or per-attachment ACL? Those are not core CouchD=
B
> >> features.
> >>
> >>
> >>>
> >>> - background events are a reality too and they enable Couchapps to
> >> perform
> >>> any kind of background REST events:
> >>>  - send email, SMS, payments, scheduled backups.. and so on.. just by
> >>> interacting with the database
> >>>  - all these jobs can eventually be packed into single-feature-ready
> >>> couchapps: e.g. "do you need stripe payments on your website?".. just
> >>> download the stripe couchapp!
> >>>  - the daemon is opensource and implemented in node.js,
> >>> https://www.smileupps.com/couch-daemon-triggerjob ... but it would be
> >> great
> >>> ported to erlang
> >>>
> >>> I agree with ermouth a lot can still be done around tooling,
> performance
> >>> and scalability (do you think bigcouch can eventually help us on this
> >>> too?), but I think leaving Couchapps could be really a great error.
> >>>
> >>>
> >>> 2015-05-05 11:49 GMT+02:00 Jan Lehnardt <jan@apache.org>:
> >>>
> >>>>
> >>>>> 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 an=
d
> >>>> 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 CouchApp=
s
> >> are
> >>>>> and why one should move forward to sth. better. With clarification
> >> comes
> >>>>> clarity
> >>>>
> >>>> Thanks Andy! =E2=80=94 I=E2=80=99m all for the things you mention, o=
nce we figure out
> >> how
> >>>> the CouchApps story fits into the larger CouchDB story without
> confusing
> >>>> anyone.
> >>>>
> >>>> What=E2=80=99s your take on that? :)
> >>>>
> >>>> * * *
> >>>>
> >>>> Also, I think we shouldn=E2=80=99t be afraid to make CouchApp=E2=80=
=99s place in
> >> CouchDB=E2=80=99s
> >>>> history clear in terms of =E2=80=9CThis was an idea of its time. Tod=
ay, we
> think
> >>>> differently. RIP CouchApps=E2=80=9D.
> >>>>
> >>>>
> >>>> 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=E2=80=99ve 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=E2=80=99t need t=
o run any
> >>>> other
> >>>>>> infrastructure
> >>>>>> - this is the future of web development
> >>>>>> - couchapp* is a great tool to manage design docs
> >>>>>>
> >>>>>> (*or erica=E2=80=A6 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 nee=
d.
> >>>>>> - 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=E2=80=99s think about how (and if) we can fit the CouchApp sto=
ry into a
> >>>>>> coherent CouchDB story.
> >>>>>>
> >>>>>> A prerequisite for that is having a coherent CouchDB story, which =
we
> >>>> don=E2=80=99t
> >>>>>> have fully finalised yet, but we have talked about extensively, an=
d
> >> the
> >>>>>> consensus is around the =E2=80=9CData where you need it=E2=80=9D n=
arrative that
> >>>> emphasises
> >>>>>> replication between CouchDB instances and other projects that spea=
k
> >> 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=E2=80=99t meant as a basis for discussion)
> >>>>>>
> >>>>>> I=E2=80=99m personally conflicted. When we set out to develop Couc=
hApps, 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 we=
b.
> >>>> That
> >>>>>> didn=E2=80=99t happen and probably was a little foolish of us :D
> >>>>>>
> >>>>>> Technically, that would have meant CouchApps had to grow a lot mor=
e
> >> 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 alread=
y
> >> 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 chanc=
e
> of
> >>>>>> making CouchDB=E2=80=99s unique features (replication, _changes) a=
vailable
> >> for a
> >>>>>> larger population and I=E2=80=99m infinitely excited about that.
> >>>>>>
> >>>>>> * * *
> >>>>>>
> >>>>>> All that doesn=E2=80=99t mean, however, that CouchApps don=E2=80=
=99t have their
> place,
> >>>> but
> >>>>>> again, I=E2=80=99m not sure where that place is and the place it c=
urrently
> has
> >>>>>> seems to negatively affect CouchDB, so I=E2=80=99d like for this l=
ist to
> think
> >>>> and
> >>>>>> talk about all that for a bit.
> >>>>>>
> >>>>>> How can we make it that CouchApps strengthen CouchDB and not weake=
n
> 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 =E2=80=93 I =
say =E2=80=98No=E2=80=99
> >> and I
> >>>>>> can
> >>>>>>> prove it. Couchapps have a lot, A LOT of problems, and some of th=
em
> >> can
> >>>>>> not
> >>>>>>> be solved inside CouchDB. For example, try to implement ACL for
> >>>>>> attachments
> >>>>>>> or try to scale couchapp. You just can=E2=80=98t do it in reasona=
ble way.
> >>>>>>>
> >>>>>>> I know several engineers who tried out couchapps =E2=80=93 and le=
ft CouchDB
> >>>>>>> forever. Not because CouchDB itself, but because couchapps.
> O=E2=80=98Reilly
> >>>> said
> >>>>>>> it=E2=80=98s a silver bullet, others said =E2=80=93 and what we h=
ave? 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 =E2=80=93 there is no need to lie and say couc=
happs are
> >>>> great.
> >>>>>>> Because they are not.
> >>>>>>>
> >>>>>>>> would you like to write down some of your positive:-))
> experiences?
> >>>>>>>
> >>>>>>> http://ermouth.livejournal.com/tag/couchdb =E2=80=93 sorry, Russi=
an
> >> 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/
> >>>>
> >>>>
> >>
> >> --
> >> Professional Support for Apache CouchDB:
> >> http://www.neighbourhood.ie/couchdb-support/
> >>
> >>
>
> --
> Professional Support for Apache CouchDB:
> http://www.neighbourhood.ie/couchdb-support/
>
>

--90e6ba1efd82c47e0a051554ad78--