hi jukka
I'm not implying that the suggested solution in OAK-660 is wrong (apologies if that was how I sounded)
ack
, just trying to understand why it was chosen
it's not yet chosen... its work in progress and am still in the very first iteration (compared to us having up to 5 different mk implementations and still don't have a final decision on how to build it). i am currently trying to complete that, fill in the TODOs and FIXMEs in order to be able to verify if it works in the first place and second how it performs.
(pre-load content in memory, refresh/reload when changes are detected) unnecessary with Oak. If it's needed, then there might be some problem lurking around that we haven't yet considered.
i don't want to pre-load content but i am convinced that just reading the permission content (which is already a compiled form of the original AC content) for every single call of 'hasPermission' will not perform irrespective on how precise the compilation in the content will be... if it turns out that i am mistaken i will adjust it in the subsequent iteration.
More specifically, what's the cost of permission compilation and, if too high to be done on-demand, what's the trade-off between storing the compilation results in memory vs. in content? Also, what's the benefit of a separate permission store vs. reading permissions directly along the path being accessed?
see above... how can i generate figures if i don't get an initial version running because i keep discussing? it's a first version that includes what IMHO would be a likely start for being a scalable, high performing ac-evaluation taking both oak specifics and my experiences from cq2 up to jr2.x into account. it will evolve and be adjusted based on concrete numbers and input. that doesn't differ from any other area in the oak project.
PS. Angela, I know this must be annoying, with people asking questions and bringing up alternatives, just to end up with "ah, right, I didn't know that!"
it wouldn't be annoying at all if people would invest some time looking at the code and understanding the existing setup and the requirements before guessing how it could be or not and starting discussions on how it should be or not based on assumptions. that's my precondition for a serious discussion. discussions just for the sake of mail traffic and visibility is futile.
But these discussions help spread knowledge and understanding about the security code and thus hopefully make it easier for others to participate in the effort if or when needed.
see above: that's perfectly fine if the discussions are qualified. if they are not they will simply make no difference but instead just prevent me from completing a task that is months behind the schedule. regards angela
