Apologies in advance for the rant:
I am not sure face-to-face meetings, unless if you count google hangouts, would be a practical solution. Our volunteering is just affected by so many things that really make this an unviable option. I would however welcome weekly (or even biweekly) developer calls to review scope, planning and roadmap for the project. This seems like our best bet moving forward and we just have to come up with a schedule that works for the majority. >From a pure technical point of view, I’d welcome any and all design discussions/suggestions around the roadmap of the project. Using spring-webflow to model the authentication sequence seems like a reasonable approach (although before fully moving in that direction I suppose we really need evaluate the roadmap for SWF and see where it’s headed. Discussions around SWF3 date back to 2010 which is somewhat alarming). Removing configuration overhead and identifying knobs and settings that are no longer actively pursued are most welcome. Decoupling CAS to resolve around a set of small microservices (which seems to be the buzz word these days) is also perfectly sound idea. >From a functional/practical point of view, I am not sure we can, or even need to afford changes of that magnitude in one shot. Big design only works if we can afford the time, patience and energy to go through with it and it’s obvious at least to me that we can’t budget it that way. While it’s perfectly fine to ponder, elaborate, document and discuss design points and come up with a big picture, it’s impractical and frankly unnecessary to implement at this point. I am not sure, personally, if I feel the same pain points as you do. Sure, there are a few things that could be improved but I am struggling to find a practical rationale and use case that would actually benefit our adopters and community through big change. Maybe I am ignorant, but I can’t find any that would justify this. It’s true that support for multiple protocols could be vastly improved and rewritten, but I am not sure there is a demand for this big change or that we have use cases and requirements available to us that are just presently impossible or super painful to implement. At least not in one big swoop. I would much prefer if we came up with a design and a rationale behind that design based on actual use cases and requirements demanded by the community, and then slowly but surely march towards the goal. It may seem wasteful upfront, but it’s also unfair to ask any individual to go off with a design doc and come back with 50000 LOC and a shiny new system. Now, don’t get me wrong; I would love to spend time to figure out what CAS NextGen (that just sounded way too commercial, didn’t it?!) would look like but I do also realize that at this point, with our budget, time, effort and level of collaboration amongst other obligations that time spent would mostly just amount to a theoretical exercise. Of course, I could be persuaded otherwise. Now, I am sure (and I have been guilty of this myself) that we could communicate our task list and ideas better on the list to give everyone an overview of and a deep-dive into what we’d each like to work on and what possible solutions for those might exist, before the presentation of the code for the ideas! This definitely would be more collaborative, and as Scott says, would help with the code review process as well. It’s all about giving, sharing and receiving :) If we all synchronize our watches on the same of features and changes, it would definitely be progress in the right direction. I have personally tried to use our issue tracking system to document ideas and features herw and there and have been using the list less, but I could change. Have a great thanksgiving weekend, everyone. From: Jérôme LELEU [mailto:lel...@gmail.com] Sent: Friday, November 21, 2014 7:36 AM To: cas-dev@lists.jasig.org Subject: Re: [cas-dev] CAS design perspective from the outside 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: 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 as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
