> 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 - 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/ > >
