Open rklaehn opened 2 years ago
So the Acl contains all the info to decide permissions questions, and it is already a tree.
Currently it is doc.peer.<path> => Rule
, right?
Sounds about right
Any particular reason it is doc.peer
and not peer.doc
? It seems that peer.doc.path.
would be closer to how the paths are modeled in the store.
Don't recall. If there was a reason it needs to be reevaluated now anyway.
So looking at it some more, it seems the reason to have doc first is to be able to subscribe selectively to a doc.
When implementing join, I can do many things using very fast radix tree ops. E.g. removing expired from the store can be done with a single tree op instead of a loop.
E.g. this loop
can be turned into this:
However, operations that involve permissions at present still involve querying permissions for every path.
It would be quite useful if we had a way to produce a tree for a permission and a peer, and then perform bulk operations for that tree. This would not change except when permissions are changed.
E.g.