All, As part of the CAS4 roadmap/development, I'm looking at the currently available modules/add-ons for CAS3 and evaluating which should be migrated to CAS4.
We currently have the following modules (not including core and webapp): * Compatibility * BerkeleyDb Support * JBoss Cache Support * Memcached Support * RESTful API via Restlet * Generic Handlers * JDBC Handlers * LDAP Handlers * Legacy Handlers * OpenId 1.1 Basic Support * RADIUS Support * SPNEGO/NTLM Support * Trusted Support * X.509 Support Currently Arnaud handles the SPNEGO/NTLM support and I'd be extremely happy if he migrated that to CAS4. Similarly, Velpi currently manages X.509 and I'd like to see that migrated. Rutgers specifically has an interest in ensuring that Memcached support, RESTful API, and LDAP are migrated. In addition, I would be willing to ensure that the "Trusted" support would be migrated as its a key integration point. (in addition, not listed here, but included as part of core would be the JDBC Ticket Registry) That leaves the following modules: * Compatibility * BerkeleyDb Support * JBoss Cache Support * Generic Handlers * Legacy Handlers * JDBC Handlers * OpenId 1.1 Support * RADIUS Support Intuitively, it would seem the "Legacy" support for the CAS2 Password Handlers has minimal usefulness at this point (CAS3 has been out for over 3 years). Similarly, the generic handlers are essentially enhanced test handlers. Unless someone had a strong interest in supporting them, my inclination would be not to migrate them. The RADIUS and JDBC handlers seem like they would be useful to continue supporting. Is anyone interested in maintaining them (i.e. taking ownership of them)? They'd most likely be migrated either way, but merely as is instead of with improvements that may be necessary/useful. With the understanding that JBoss Cache underperforms compared to the Memcached client, is it worth transferring JBossCache over? Similarly, with the JpaTicketRegistry, is it worth having BerkeleyDb also? (it may since BerkeleyDb is long term storage on disk). Clearly, if anyone steps up, even if I don't find them useful, we'd be willing to migrate. Thoughts? Comments? -Scott -Scott Battaglia PGP Public Key Id: 0x383733AA LinkedIn: http://www.linkedin.com/in/scottbattaglia _______________________________________________ cas-dev mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas-dev
