> On Jan 27, 2016, at 3:17 PM, Chris Pike <[email protected]> wrote: > > started implementing this and one of the things I am concerned with is > duplicate ftPA entries. Most of our permissions will likely share the same > attribute(s), so the ftPA entires will be duplicated across several > permissions in what I proposed. I am considering creating an objectclass, > something like ftAttributeSet to store the attribute(s), then have ftPA point > to the attribute set. Then in the ftRC, for the filter type, I can specify > the attribute set instead of trying to infer which one is applicable. Any > thoughts or concerns with that change? > > FYI - My plan is to provide an ldif export with some sample data once I have > it all implemented, but if you are interested in what I've done so far you > can take a look here > (https://github.com/PennState/directory-fortress-core-1/tree/feature/addPermAttrAndUserRoleConstraints). >
My first thoughts are storing the ftpa attribute set in a separate node or tree adds at least one read to every operation and should be avoided at all costs. What we’re talking about here are rules. And these rules can be used across many permissions. My question is how many of these rules can we expect to be using? Maybe we store them as properties: ftPa1:xyz ftPa2:abc ftPa3:def ftPa4:ghi Now your ftPa attribute on the permission needs to store the name of specific rule it is using. Those config parameters will eventually be stored in the tree under node, ou=Config. The difference being here, those parameters are all read, and cached by the config subsystem when process fires up.
