jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: Permission handling (Was: [jira] [Commented] (OAK-660) ReadOnlyTree: implement Object#equals and Object#hashCode)
Date Mon, 04 Mar 2013 08:47:48 GMT

On Fri, Mar 1, 2013 at 3:46 PM, Angela Schreiber <anchela@adobe.com> wrote:
> 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.

My main worry here is that we end up with a similar situation as with
the original MongoMK. After months of effort we essentially needed to
start from scratch since the implementation didn't take into account
the broader design of Oak.

You're obviously in a much better position to understand how the
different pieces of Oak fit together, so I'm not too concerned, but I
assume you'd agree that others could have valuable input on how to
best fit permission handling with the rest of the stack.

> see above... how can i generate figures if i don't get an initial
> version running because i keep discussing?

Even a general description of why you believe one approach to be
better than the other would be fine.

See for example my original MongoMK^2 design proposal where I outlined
the SegmentMK design together with rough estimates of some key
performance characteristics. I don't yet have exact numbers to back up
all those estimates, but they are still quite valuable in discussing
the overall design and in figuring out whether implementation or
design changes are needed to address specific issues.

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

The code can only tell you *how* it currently works, not *why* it
works like that or how it'll work once the implementation is
completed. The reason I bring up these discussions are the latter
questions, i.e. when I can't find answers to my questions just by
looking at the code.

For example, I see the canRead() methods on PermissionProvider and I
wonder whether those calls really need to be made on each and every
Tree access. Since a Tree is based on an immutable snapshot of the
repository, we should be able to tell whether the current user has
full read access to content in that subtree. If that's the case (which
it commonly is), it would be possible for us to avoid *all* remaining
canRead() calls in that subtree, which would be a great performance
gain regardless of how far the canRead() method itself can be


Jukka Zitting

View raw message