Andrew is pretty spot on in his assessment of things. The code that does exist lives here: https://github.com/Jasig/person-directory/tree/pd-2-dev
There is something that might pass for a design (well more like a brain dump) in https://github.com/Jasig/person-directory/blob/pd-2-dev/notes.txt The goals were: - Fix the API and the horrible abstraction mess in PD1.X. A big part of this was creating an external API that things that used PD2 would call and then an internal SPI that things that provided attributes would implement. This simplified things A LOT on the attribute source side. - Fix the project structure. You'll notice there are api, spi, core, util, and jdbc modules. core is where all the actual attribute resolution, concurrency, merging, etc logic lives. jdbc is an example spi producer with the intent that there would be many more to come. - Improve performance by making all attribute lookup concurrent - Simplify configuration. The idea is you'd just configure a bunch of attribute sources. No need to define call order, chaining, etc. The core logic figures out which sources to call and in which order to satisfy the query. - Add a real query API via critera <https://github.com/Jasig/person-directory/tree/pd-2-dev/person-directory-api/src/test/java/org/jasig/services/persondir/criteria> classes, this allowed for actual logical queries to be executed and subsets of those to get executed against attribute sources. So with all that, the code that is there is semi-functional but it isn't great code. It is the result of me hacking on something in my spare time and more idealistic and realistic at this point. I still think there are some great ideas and the code just needs some real cleanup (and probably a real design doc first). I honestly think it could be very valuable to schools that have more than a few attribute sources in person directory. All that IO of serially searching for attributes for a user is REALLY expensive and slows down login quite a bit. Also getting rid of the giant and complex configuration in favor of a flag collection of attribute sources that the rest of the code just knows how to use would go a long way in improving things too. Hope that all helps and good luck with whatever you do with it. On Wed Dec 17 2014 at 8:31:28 PM Andrew Petro <[email protected]> wrote: > > 1. Goals: > > * Improved performance through among other things better concurrency ? > * Perhaps beat back the significant complexity and > inheritance-over-composition that has grown into the PersonDirectory > codebase over time? > > 2. Accomplished? > > * there's some code > * it's abandonware that could be adopted and un-abandoned > > 3. What next? > > Well, either finish it, or find a way not to need it (instead adopting, > say, the Shibboleth IdP AttributeResolver APIs? Something else? Has > anyone other than Jasig / uPortal / Apereo nailed the problem of querying > user attributes? Gathering and transforming user attributes is one of > those things that an Identity Provider is *about*, so maybe there's a way > to use those APis and implementations and not have to develop and maintain > PersonDirectory code anymore?) > > :) > > Adopters of Shibboleth and of uPortal might appreciate the synergy in the > attribute gathering plugins being the same API to plug in to so that > attribute gathering configuration solutions that have been developed for > one product are more readily applicable to the other product. > > Kind regards, > > Andrew > > > > > > On Wed Dec 17 2014 at 5:14:34 PM Misagh Moayyed <[email protected]> > wrote: > >> Eric (and others), >> >> I wasn’t sure what would be the best forum to talk person directory, and >> so I’ll get started here and you can tell me if this can better be >> discussed offline, etc. >> >> >> >> I am interested to learn more about person directory v2 and what we can >> do to complete it. I know Eric was working on that project for some time >> but I am not sure where we ended up with that. So I would appreciate if >> anybody, especially Eric, could share insight on: >> >> >> >> 1. What does v2 plan to accomplish in terms of goals? >> >> 2. What has so far been accomplished in view of those goals? >> >> 3. What is left to do? >> >> 4. What can we do to help? >> >> >> >> Any form of documentation, short of looking at the code, would be great >> to get started. >> >> >> >> Misagh >> > -- >> >> 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/uportal-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/uportal-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/uportal-dev
