> On 05 May 2015, at 13:17, Giovanni Lenzi <[email protected]> wrote: > >> How do you do per-doc or per-attachment ACL? Those are not core CouchDB > 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 some > minor improvements to rewriting engine module. > > > > 2015-05-05 13:01 GMT+02:00 Jan Lehnardt <[email protected]>: > >> >>> On 05 May 2015, at 12:54, Giovanni Lenzi <[email protected]> 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 CouchDB >> 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 <[email protected]>: >>> >>>> >>>>> On 05 May 2015, at 11:08, Andy Wenk <[email protected]> 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 <[email protected]> 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 <[email protected]> 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/ >>>> >>>> >> >> -- >> Professional Support for Apache CouchDB: >> http://www.neighbourhood.ie/couchdb-support/ >> >> -- Professional Support for Apache CouchDB: http://www.neighbourhood.ie/couchdb-support/
