Hi, 2014-11-20 16:20 GMT+01:00 Marvin Addison <marvin.addi...@gmail.com>:
> I've been wanting to do some big design work on this project for years, > and I finally got my chance: by contributing CAS protocol support to Shib > IdPv3. I am very pleased with the end result and it's worth noting a few > broad design points that are worth considering for Jasig/Apereo CAS: Contributing a full SAML support to CAS server would have been a great design work as well ;-) 1. Everything is a flow. I proposed this a while back for Jasig CAS and got > a lukewarm response, but I was able to work though all the details to > produce a clear, testable, and extensible implementation. Moreover the > experience has proved that Spring Webflow is an excellent facility for > modeling arbitrary protocol logic for a multi-protocol SSO product. > I guess we all agree on this. 2. Small set of simple core services, e.g. storage, session, messaging, on > top of which the protocol logic is built. You can see how I leveraged a > stupid simple storage service to model proxy chains [1,2] while avoiding > the huge headaches of Java serialization that have plagued us for years. > I'm not sure to follow you here. We have used Hibernate for DB persistence and Kryo also for Memcached (and truly it has caused problems but upgrading Kryo would help us a lot). A very promising direction we have taken recently is to use more and more JSON serialization. 3. Configuration points that matter. I think CAS has become too > configurable out of the box. Service ticket usage count is an excellent > example of a configuration point that no one uses, but there are countless > others that have marginal value. We invite support headaches and increase > development costs by allowing configuration in most if not all components. > Reduce and simplify. > Certainly, so let's remove useless features. I'm sure a PR removing ticket usage count would have been successfully +1. My sense is that we're spending inordinate amounts of time discussing > relatively minor changes, and anything that touches on design becomes mired > in endless discussion. Here's a few current or recent issues that I thought > were symptomatic: > > https://github.com/Jasig/cas/issues/669 > https://github.com/Jasig/cas/pull/730 > https://github.com/Jasig/cas/issues/695 > > Extensive discussion for small changes is wasteful; we're a small team and > we don't have the resources to suffer inefficiency. > > Spending BIG time on BIG changes, on the other hand, is healthy and > productive. I encourage some BIG design work in the near future, and > face-to-face meetings might be the most productive. A recent cas-pmc thread > suggests Apereo is willing to support F2F meetings, so it seems like an > opportune time to consider some serious in-person design work. > Yes, we must be efficient and spend most of our times on big changes. I would not say that these discussions you mentioned are useless, it helps us update our thoughts and reflection. But we could have done better because we really need design meetings to synchronize together. But because of our time zones and constraints, it has always been difficult. With Scott trapped at work and me in France, it's pretty difficult to find the right schedule and I'm willing to do that during week-ends if it's possible. Moving to US regularly for design meetings is not possible for me, but I should come to next Apereo conference: I don't know how other contributors feel to meet in US: is it something easy for them? Because we can setup video conference: not perfect, but close to a face-to-face. Your post sounds negative, but it's not how I feel. Involvment in open source is not easy unless you are alone on your project and if we don't have made major step lately, I think it was interesting small ones at least. Thanks for sharing your thoughts. Best regards, Jérôme -- 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
