> One of the things I've been working on with CAS4 is that Tickets, and the > items they depend on, have implementations specific to the backing store (so > that Authentication isn't lumped into a BLOB, for example).
That sounds like a good change, and will be more flexible in the long run as tickets are used to support multiple protocols that may have vastly different needs. > Its actually a huge pain in the butt ... it will make us think more about > what we support since there needs to > be implementations specific to each item we support Careful thought to what we support is a good thing. > (in CAS4, registries are also responsible for > knowing how to clean themselves). That sort of design will relieve the problems caused by a one-size-fits all approach like DefaultRegistryCleaner. > Another option, that may help with CAS3 is to encode > the expiration logic into the cleaners. That's where I'm headed. The tricky part will be to make configuration straightforward, but I'm hopeful it won't be too bad. > The reality is that most people don't change the actual > expiration policies, just possibly the time limits. That sounds like a reasonable assumption. Thanks, M -- 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
