hi michael i don't want to create yet another implementation that doesn't fit our requirements... we had too many escalations due to the limitation of jackrabbit core without being able to address them.
you have been involved in the recent discussion with our soco team and they are definitely looking for scalable repository without limitation in terms of access control content. in other words: i want to ship oak with a ac setup that not only covers the default setup. already with jackrabbit-core it was possible to configure custom implementations of the permission evaluation and i just know of one single case where this was actually considered an option. that's why i came to the conclusion that we have to make sure that we get rid of these limitations out of the box. at the same time the permission eval should still be pluggable such that we can extend or even replace the current model. but i consider this an option for completely replacing the evaluation model (e.g. each document comes with it's own permissions and there is no inheritance at all)... i don't want to offer pluggability as as workaround for limitations of the implementation. that's what we had in the past: the limitations were known and communicated even before releasing jackrabbit 2.x and i was always told that it's not a problem. this was simply not true... i learned my lession :-) kind regards angela On 10/7/13 9:59 AM, "Michael Marth" <[email protected]> wrote: >Hi Jukka, > >you are right that the majority of repositories we see (or at least that >I see) have few principals and few ACLs. But as Angela mentioned there is >a not-so-small number of cases with a very large number of principals >(>100000, e.g. a public portal or forum) and/or a large number of ACLs >(>50000, e.g. Intranet where ACLs are not hierarchic). >From my POV it makes sense (as it was suggested on this thread) to >optimize for the normal case (few ACLs) out of the box, but make the ACL >evaluation pluggable, so that different strategies could be used in the >different scenarios. > >my2c >Michael > >On Oct 5, 2013, at 5:31 AM, Jukka Zitting wrote: > >Do we have real-world examples of such ACL-heavy repositories? Do they >also require optimum performance? I'm not aware of any such use cases, >but that of course doesn't mean they don't exist. > >If possible I'd rather avoid the extra complexity and go with just a >single strategy that's optimized for the kinds of repositories we >normally see. >
