Mark H. Wood wrote: > I've been working to integrate single-signon code which needs to fetch > some identity data from an LDAP directory when creating a new EPerson. > It seems to me that this is wrong; if such data come from an external > service, DSpace should just get them that way whenever they are > wanted. Yes, we need a way to identify an account with a person or > role in the physical world, but we shouldn't be maintaining possibly > stale duplicate information if we don't have to. > > What I'm thinking is that EPerson should be skinned down to just the > minimum that DSpace needs for its own operation. One of those > data would be, "where do we get identity data for this account?" Then > a plugin can be consulted for those data. >
Aren't the lifetimes of an EPerson and an LDAP directory entry potentially very different? In a case where the LDAP directory entry goes away but the EPerson lives on, what is the expected behavior and the minimum data required in that orphan EPerson? ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
