jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: Permission handling (Was: [jira] [Commented] (OAK-660) ReadOnlyTree: implement Object#equals and Object#hashCode)
Date Fri, 01 Mar 2013 13:46:22 GMT
hi jukka

> I'm not implying that the suggested solution in OAK-660 is wrong
> (apologies if that was how I sounded)


>, 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.


View raw message