Hi, On Fri, Mar 1, 2013 at 3:46 PM, Angela Schreiber <anch...@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 optimized. BR, Jukka Zitting
