Hi, On Mon, Oct 7, 2013 at 3:41 AM, Angela Schreiber <[email protected]> wrote: > we never have aces that effect just one single node.
I included it just as the simplest possible example of how custom restrictions could be implemented with the proposed state machine model. > similarly it's one of core requirements of oak that we no longer > have a limitation with the number of access content entries > defined in the content tree. The algorithm I outlined is not limited by the total number of ACEs in the tree, just by the number of ACEs in the ancestor nodes. And if we expect that to be a limiting factor, we can always pre-sort the ACEs by the affected principal like is now done with the permission store. > we definitely do have need for huge amount of ac content without > having any performance draw back... it might well be that you are > not aware of these use cases but feel asserted that they exist > and that i am not going to invent use cases that make the whole > story complicated if i can have it simple. Could we have at least rough descriptions of the main use cases you're thinking about. Just simple drafts like the paragraph example I used should be a good start. Otherwise it's very difficult to estimate how well a particular design will work in practice. See http://markmail.org/message/7nn6kiotvoallrfw for my related message months ago. If we had done that exercise back then, we could already have spotted the current performance issue with a simple calculation like the one I did in earlier in this thread. I'd hate to see us spend another few months implementing something different, only to realize that it won't perform well enough for one use case or another. > tobi and myself had a lot of discussions during the oakathon last > week regarding access control and security requirements in general. > no final decisions yet... but a lot of ideas that we kept collecting > over last couple of years. Can you write up a quick summary of the discussions? BR, Jukka Zitting
