Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • (quick!) History outline describing how we got to where we are today
  • (quick!) Where we are today
  • (quick!) Shorcomings of the status quo
  • Options for addressing and decisions
    • Where are the APIs CasConnectionContext and ICasSecurityContext going to live? uP source tree? jasig-java-cas-client source tree?
    • What work to be done at code level. Who will do it?
    • Documentation desperately needs help. how do we make it better how?
  • Potential for uPortal-CAS combined quickstarts
Note
iconfalse
titleWhy meet? What to discuss?

The very first and perhaps most important point of the meeting is to meet, to convene interested parties to discuss and achieve mindshare on goals, strategy, and tactics.

I put some ideas for items for discussion on that wiki page. I'll update it with this verbiage.

The topics for discussion at the meeting may best be understood in terms of the goal of the whole effort: make it easier and more easily understood how to CASify a uPortal.

Goals are probably the first thing to discuss. What are these APIs trying to accomplish? What is the goal of the JA-SIG Java CAS Client's uPortal integration subproject?

The meeting is to discuss which ICasSecurityContext APIs to standardize on, whether and which CasConnectionContext implementation to standardize on, and what to do about the various implementations – presumably make them implement whatever shared APIs are standardized on, but maybe to retire one or the other.

We could decide to keep the existing implementations where they are and improve them to share APIs.
We could decide that the JA-SIG Java CAS Client should provide the authoritative APIs and uPortal source tree should stop including these APIs. (I don't think this is a good idea – I think the APIs should be defined in the uPortal source tree since they feel "about uPortal")
We could decide that uPortal should ship with the APIs defined in its source tree but instead of including source code for implementing CAS security contexts, it should include the ja-sig Java CAS Client .jar and use those, retiring the defined-in-uPortal-source-tree-implementations.
We could decide that uPortal should ship not just with the APIs in its source tree but also the implementations there defined, and retire the uPortal portion of the JA-SIG Java CAS Client source tree, scoping that project back to just defining the general Java CAS Client piece. uPortal ships with the JA-SIG Java CAS Client .jar and includes the source code for integrating with it.

There are a plethora of options here. The meeting is to discuss their merits and arrive at a plan of attack.

Also to discuss documentation – what documentation will be updated by whom. Improving the code to follow a well-defined plan won't be as valuable if we don't make it clear to would-be consumers.

If we have time and aren't too exhausted, it could be worthwhile to discuss the prospects of embedding a CAS server instance in uPortal by default. That was discussed at the dev meeting and I think I'm starting to make inroads in people seeing this as not just a quickstart toy trick but a potential core feature of uPortal, to be using a CAS server under the hood.