What you're describing was what was being worked on in the cas4-api feature branch. I'm still in favor of that approach, so +1.
On Wed, Dec 18, 2013 at 9:17 AM, Marvin Addison <marvin.addi...@gmail.com>wrote: > > +1 on a comprehensive strategy down the road to ease this process. > > Ok, since there's some interest I'll discuss my vision further. As I > see it, one of the core issues is the assumption of a one-size-fits > all set of components for every storage technology. In particular > we've got JPA annotations floating around in the same components that > are explicitly serializable. Both capabilities impose some oddities on > the component design but you would never need both for a single > storage solution. Additionally, there's no opportunity to engineer for > optimization for one technology without affecting all the others. > (Storing the Map<String, Service> of visited services in > TicketGrantingTicketImpl as a BLOB in the JPA case comes to mind as > good example of poor tradeoffs.) > > Solving this problem will indeed require a comprehensive approach: a > generic SSO session API with technology-specific implementations. I'm > fairly certain we need to ship at least the following: JPA, > Serializable, and JSON. That's a lot of work and probably in scope for > a 5.0 release at the earliest. In my view it will be well worthwhile. > > M > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > 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 as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
