At Eastern Washington University, we currently have 40 entries. CAS is still relatively new at our institution and we still have quite a few applications to switch over. I wouldn't be surprised if we ended up with 60 or more by the end of the 2012 calendar year.
From: Scott Battaglia [mailto:scott.battag...@gmail.com] Sent: Friday, December 23, 2011 9:39 AM To: cas-dev@lists.jasig.org Subject: Re: [cas-dev] Thoughts on CAS-1013 I think you bring up a question we need answered though: on average, how many services do people have in the tool? On Fri, Dec 23, 2011 at 12:31 PM, Joachim Fritschi <jfrits...@freenet.de<mailto:jfrits...@freenet.de>> wrote: I agree with Scott on the point. Having some really complicated automatic algorithm won't help much because you would still need a manual override. Any people need to understand the automagic ;) The simple ordering by in the gui is fine but once you hit 100s of services i would rather have some kind of hirarchical assessment possibility. I think it could be helpfull to have this option because it would allow an easy ordering of services, clean up the admin gui by allowing "grouping" and also increasing performance during evaluation. This would allow separation of subdomains, domains, directories etc. One could even think about some additional client level (different user pool, design for different clients) Any top level service would always get checked unless you have a match. Any subservice would get evaluated once a top level service gets matched. The deepest service "wins". This can be coupled with permission inheritance and many more features ;) Just a crazy thought... Regards, Joachim Am 23.12.2011 05<tel:23.12.2011%2005>:14, schrieb Scott Battaglia: Again, why don't we just make it so you can drag and drop the order from the management screen UI. The last thing you want to do is give people the option of ordering and then change the order that they gave you. On Thu, Dec 22, 2011 at 7:14 PM, Misagh Moayyed <mmoay...@unicon.net<mailto:mmoay...@unicon.net> <mailto:mmoay...@unicon.net<mailto:mmoay...@unicon.net>>> wrote: 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<mailto:marvin.addi...@gmail.com> <mailto:marvin.addi...@gmail.com<mailto:marvin.addi...@gmail.com>>] Sent: Tuesday, December 20, 2011 7:14 AM To: cas-dev@lists.jasig.org<mailto:cas-dev@lists.jasig.org> <mailto:cas-dev@lists.jasig.org<mailto: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<mailto:cas-dev@lists.jasig.org> <mailto:cas-dev@lists.jasig.org<mailto:cas-dev@lists.jasig.org>> as: mmoay...@unicon.net<mailto:mmoay...@unicon.net> <mailto:mmoay...@unicon.net<mailto: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<mailto:cas-dev@lists.jasig.org> <mailto:cas-dev@lists.jasig.org<mailto:cas-dev@lists.jasig.org>> as: scott.battag...@gmail.com<mailto:scott.battag...@gmail.com> <mailto:scott.battag...@gmail.com<mailto:scott.battag...@gmail.com>> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed tocas-...@lists.jasig.org<mailto:tocas-...@lists.jasig.org> <mailto:cas-dev@lists.jasig.org<mailto:cas-dev@lists.jasig.org>> as: jfrits...@freenet.de<mailto:jfrits...@freenet.de> 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<mailto:cas-dev@lists.jasig.org> as: scott.battag...@gmail.com<mailto:scott.battag...@gmail.com> 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<mailto:cas-dev@lists.jasig.org> as: jgas...@ewu.edu<mailto:jgas...@ewu.edu> 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
