If it was fast enough, it'd be nice to be able to. but i haven't seen
anything configured in person directory yet, that was 'fast enough' to
skip caching. It would certainly be very rare right now.
---- Cris J H
On 08/10/2011 04:22 PM, Eric Dalquist wrote:
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
--
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
