If my voice counted, I'd +1. But letting my opinion known anyway. In the spirit of modern, micro-service-based architecture, I'd wanted to have CAS core be small, cohesive, de-coupled. Do its core thing (CAS protocol, Web SSO) well, and also expose its configuration model as set of focused REST services (with JSON representation of the model, for example), so that would enable all kinds of UIs, and tools to be built around (outside of the main CAS server source repository).
Cheers, D. Sent from my iPhone > On Jul 26, 2015, at 11:59, Misagh Moayyed <[email protected]> wrote: > > +1 to moving it to a separate project. > > From: Jérôme LELEU [mailto:[email protected]] > Sent: Sunday, July 26, 2015 7:08 AM > To: [email protected] > Subject: [cas-dev] Drop the management webapp > > Hi, > > The CAS service model has strongly evolved for the CAS server v4.1 and the > powerful new policies are hard to define through a UI. Maintining this webapp > requires a lot of work. > The default services registry is now based on JSON files which also makes > manual editing a lot easier. > > I'm in favor of dropping the CAS management webapp or maybe first moving it > into a separate project. > > I'd like to get feedbacks on this idea: do CAS deployers use it? How? > > Thanks. > Best regards, > Jérôme > > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
