Some other things I'd like to see done in person directory:

- Add a real query API (see http://static.springsource.org/spring-ldap/docs/1.2.0/api/spring-ldap/org/springframework/ldap/filter/package-summary.html for an example of something that could work as a starting point for an API design)

- Simplify configuration, perhaps write a Spring namespace handler to reduce the boiler plate, also make caching an inherent concept (are you ever really going to use PD without caching results?)

-Eric

On 8/10/11 6:08 PM, Eric Dalquist wrote:
+1

I've thought about this often and just never had the time. We use a lot of data sources at madison and it would really help login times a lot if all those queries could be shuffled off into an ExecutorService.

On 8/10/11 4:58 PM, Andrew Petro wrote:
In the course of assisting with a uPortal implementation, I've been re-familiarizing with the person-directory API and implementation.

In looking over the MergingPersonAttributeDaoImpl, I started wondering: would there often be much advantage in this code invoking the child DAOs in parallel rather than serially?

It's mostly an idle thought -- I don't have an immediate need for a parallelized implementation on this project and I'm not proposing to write this code -- but it seemed an interesting enough idea -- and potentially one right in the smack of the critical path for a successful login and render -- to be worth raising, see if anyone's done this, or sees value in it.

Andrew




Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to