Thanks Eric and Andrew. FYI backlogged Jira and referenced this thread in https://issues.jasig.org/browse/PERSONDIR-84. I'm sure many other of the unresolved PersonDir Jira issues would fall into v2 work, but that can be cleaned up later.
James Wennmacher - Unicon 480.558.2420 On 12/17/2014 10:03 PM, Eric Dalquist wrote: > 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] > <mailto:[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] <mailto:[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 [email protected] > <mailto:[email protected]> as:[email protected] > <mailto:[email protected]> > > To unsubscribe, change settings or access archives, > seehttp://www.ja-sig.org/wiki/display/JSG/uportal-dev > > -- > > You are currently subscribed [email protected] > <mailto:[email protected]> as:[email protected] > <mailto:[email protected]> > To unsubscribe, change settings or access archives, > seehttp://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
