Kevin Dangoor wrote: > > In this particular case, I think that the Identity user API is really > easy to use and will meet a good variety of needs (but certainly not > all). peak.security is the kind of thing that can meet everyone's > needs, but wouldn't be as easy for some of the common cases that > Identity is good at.
Which is why RuleDispatch offers programmatic APIs for dynamically defining methods, so you can hide the details. Just because you *can* give unlimited flexibility, doesn't mean you can't have an easy API. For example, consider this command-line options framework: http://peak.telecommunity.com/DevCenter/OptionsHowTo Nowhere is there any mention of generic functions or adding methods or criteria, but it internally uses a Dispatcher object that does lookups based on class and attribute names. So, it's not necessary to expose generic functions' complexity directly, if all you want to do is define some type of registry of rules based on standardized access patterns. RuleDispatch was created in part because I got tired of having to write new kinds of registry classes all the time for PEAK, every time there I had some new way of looking things up. RuleDispatch lets me focus on the app and not on the data structures needed to implement it. As a practical matter, however, RuleDispatch's more advanced APIs are still alpha, which is to say they're likely to change significantly in the future as I refactor to allow new features and improve the current speed/space tradeoffs. With the limited time I have to work on it, I'm not sure how long it will be before any of these things can get done.
