I have researched possible options for an algorithm that would attempt to determine the "strictness" of a regex pattern. The solution seems to come down to translating the regex pattern to minimalistic state machine from which symbol counts and number of transition states can be deduced for comparisons. Having run tests on a small C# demo app that does the translation, it turns out that this would be computationally somewhat expensive specially if done for every ticket granting request. (Not to mention the fact that IMHO it just seems unnecessarily complex.)
Going back to Andrew's use case, I certainly do agree that evaluation of services should be competent enough to address "more obvious" ones first, possibly those without utilizing a regex pattern. So as a compromise to reach a middle ground, it seems to me like we could modify the daos to evaluate the service URL on save and if no regex pattern exists, the dao would then automatically up the evaluation order of the service so it'd be amongst the very first to get examined. Does this make sense? P.S: I currently have made changes locally so services by default are sorted by evaluation order in the UI. That all looks good. -Misagh -----Original Message----- From: Marvin Addison [mailto:marvin.addi...@gmail.com] Sent: Tuesday, December 20, 2011 7:14 AM To: cas-dev@lists.jasig.org Subject: Re: [cas-dev] Thoughts on CAS-1013 > 1. I would imagine that setting up a basic numeric value to indicate > order would be much easier to understand than regular expression patterns. We want both. I'm emphatic on that point. Regular expressions are a standard pattern matching facility that any reasonably competent deployer ought to know and be comfortable drafting. We've had a number of incidents over the years where the use of Ant patterns has caused a fair bit of confusion and frustration. They're just similar enough to be misleading yet lack the expressive power of a posix regular expression. The use of an explicit order field is both clear and performant. There is no conceivable algorithm for "longest match" that would not require evaluating against _all_ registered services. Compare that to the existing algorithm that short circuits on first match. We have a growing list of services and incurring more processing overhead at the point of granting every ticket is a non-starter. I'm confident the UI issues with the current service manager are just that -- matters of user interface design. I think the ability to sort by arbitrary column would be beneficial, but they should be sorted by order by default. M -- You are currently subscribed to cas-dev@lists.jasig.org as: mmoay...@unicon.net To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev -- 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
