Misagh, I hear you on ways to make evaluationOrder more understandable, by reflecting it in the UI (ability to list in order of evaluationOrder, display the evaluationOrder attribute with the registrations listing in the manage view).
My thought is that Order is just not the right abstraction here. The current services management / services registry solution is using abstractions that are too abstract versus what would be sufficient. I expect that CAS adopters don't want more than a few overlapping patterns, and in the case where patterns do overlap, there are obviously more specific and less specific patterns, and they always want the more specific pattern to match. Getting to a programmatic algorithm for evaluating "obviously more specific" is an interesting nugget of a problem; I'll be interested to see how solvable this is. I admit I haven't given it enough thought to to know the answer offhand. Consider a typical use case. A university balancing privacy and agility in SSO integrations might want: 1) By default, any service may get a persistent, anonymous, opaque identifier 2) All services at https://portal.someschool.edu may get proxy tickets, since they're service URLs representing portlets that proxy to interesting other services 3) Specific registered services may get the username and, varying by service, other user attributes Now, suppose I go and register https://portal.someschool.edu/NetReg/login because someone decided to deploy the NetReg application into the uPortal Tomcat. It's not a portlet, I don't want it getting proxy tickets, but I do want it to get some other attributes, say. So, isn't it obvious that I'd want the https://portal.someschool.edu/NetReg/login registration to supersede the https://portal.someschool.edu/** registration? *There's no use case for unreachable registrations.* I certainly don't want to add the NetReg registration and have it have no effect. And I certainly don't want to add the registration, have it have no effect, and not be warned about this. Yes, I could take care in making my registration have the right evaluationOrder to get the desired effect, and yes, UI affordances could make it easier to take this care, but I'm wondering if the best UI affordances around evaluationOrder would be not to have it at all. That is, services registry and services management has more in common with a rules engine and less in common with a Netflix queue. I'm not queueing discs to be shipped to me, where Order and a better UI for reflecting and managing Order makes sense, since we're essentially talking about objects that necessarily really have an order. Rather, we're talking about rules for how CAS is going to treat a service URL presented at runtime. These rules have order only incidentally, because computers can only evaluate them serially and because this is how logic works. They're not inherently ordered. evaluationOrder isn't reflecting something inherent about the domain -- it's a concession to the implementation. So, it seems to me that the use cases for these registrations are simpler than the arbitrary configuration that evaluationOrder supports. I don't need the power to create registrations with relative evaluationOrder such that in practice they will never have any effect. Can I have less power and more usability? If evaluationOrder had never existed, how would CAS figure out which registration matches, and would that be good enough? I can't imagine a CAS deployment with more than 1000 service registrations. Might it actually be true that CAS could load all registrations into memory, *try every one of them*, and pick the one with the most specific pattern that matched? I'm not saying that's the right, refactored, quality algorithm to use here. But might it be the "simplest thing that could possibly work", and might it be more usable than what's there now? > if order really has to go away I don't think of it this way. This isn't a war on "evaluationOrder". Order doesn't really have to go away, or really have to be there. It's less a question of what has to go away, and much more a question of what has to be there. Isn't there some adage about a design being complete not when everything that's needed has been added, but rather when everything that is not needed has been taken away? My thought is that evaluationOrder isn't needed here, and can be taken away, and the result will be simpler and better, if it proves feasible to program the intuition of which registration "obviously" should match when two overlap. Kind regards, Andrew PS: Thought: Perhaps evaluationOrder remains as an internal implementation detail, derived from the registrations and precompiled on registry edit. On Dec 19, 2011, at 4:11 PM, Misagh Moayyed wrote: > Folks, > > Started to evaluate this new CAS feature request: > https://issues.jasig.org/browse/CAS-1013 > > Few thoughts: > > 1. I would imagine that setting up a basic numeric value to indicate > order would be much easier to understand than regular expression patterns. I > certainly would be in favor of the property, but what I find confusing is > that services management UI does not list the registered services by their > order, but sorts them using their name. I think this is pretty misleading > because you could have service A up at the top with the order 999999 and the > user would probably assume that just because it comes first, it gets to be > evaluated first as well. I think it’d be better if we modify the UI to sort > by evaluation order > > 2. Why not show the value of the order on the UI in the list of > services ? The scenario would be that if I want to register a new service, > wouldn’t it be easier to know what the order of the new service should be > beforehand rather than going back and forth between previously registered > services and trying to find what the order should be based on other services? > As the original comment on the feature says, if it’s on the main services > page, it would be a better reminder for it to be updated. > > 3. I have also looked at ANTLR to see if an existing algorithm already > exists. So far, haven’t found any other alternative. So, for starters if > order really has to go away, how about something like the following priority > order: > > a. Non-pattern URLs > b. Longer URLs > c. Prefer URLs that use “?” over those that use “**” or “*” > > Suggestions are welcome. > > -Misagh > > -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
