Jos, If by result you mean a search result, then thats a separate issue from the dynamic ACL itself, and not the direct subject of this thread. When I said performance I was referring to the atomic act of determining if the ACE was active for any attempt to access an item, not just search results.
However, thats the way jackrabbit works. JCR searches are "compiled" into Lucene Queries that generate Lucene Hits where the Lucene document contains a node ID, which is extracted in the normal manner from JCR (IIRC). If the current user cant read the item, its discarded. This is fine for dense searches where most items can be read by the user, but problematic for sparse searches. Its also problematic for sorts that can't be performed inside Lucene, as this results in all the items being loaded into memory before searching. One way to avoid sorts of this form is to ban "order by" clauses that reference any items other than properties of the node found. BTW, problematic == non scalable, vertically or horizontally. Ian On 9 Nov 2010, at 06:56, Jos Snellings wrote: > About performance: You mean that the result is generated first, and this is > filtered against the ACL. > I remember from my own experience that this was a horror in Alfresco a couple > of years ago, when a system had to query a large archive of insurance > policies. Are there plans to optimize this? > > Jos > > On 11/08/2010 03:18 PM, Ian Boston wrote: >> Oops, I see you referenced our docs on the subject, >> The scripts need to be executed on ACL evaluation since the user and time >> are input parameters. >> Since they are inside the AccessManager, the system session would be the one >> executing the scripts. >> Performance is an issue, but we normally deal with that with caching of the >> result against user. >> >> Ian >> >> On 8 Nov 2010, at 14:03, Ian Boston wrote: >> >> >>> We have been using exrta properties on ACE's to allow the >>> AccessControlManager to determine if the ACE is enabled for the current >>> user and the current time. >>> >>> Ian >>> >>> On 8 Nov 2010, at 14:01, Clemens Wyss wrote: >>> >>> >>>> Often the basic ACL features are not sufficient to represent all >>>> authorization needs >>>> (http://dev.day.com/content/ddc/blog/2009/01/theaclisdead.html ). >>>> >>>> Wouldn't it be nice if we could define our authorization needs in an >>>> "Authorization DSL" ( in Groovy or jRuby ;-) ) which then could be applied >>>> to a node, or even better a node type? >>>> >>>> What about a mixin type: >>>> >>>> [sling:ScriptedACL] >>>> mixin >>>> + sling:aclScript protected mandatory >>>> >>>> The aclScript would be written in the Authorization DSL. Predefined >>>> variables would provide access to the current node, session, etc >>>> >>>> "Dynamic ACL" >>>> (http://confluence.sakaiproject.org/display/KERNDOC/KERN-629+Time+base+ACL) >>>> would become a subset of this feature as this could be solved alike. >>>> >>>> I agree, there are still many open points such as: >>>> - who should execute these scripts? >>>> - when should these scripts be executed? >>>> - performance implications? >>>> >>>> WDYT? >>>> >>> >> >> >
