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. The profile page would need to make some fields writable or read-only depending on whether the native DSpace identity plugin or some other is used. A plugin could (if it choose) provide URLs to be provided in the profile page, linking to "for more information" or even "for the enterprise management page for this account". Comments? -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Friends don't let friends publish revisable-form documents.
pgpokSD5rQBqK.pgp
Description: PGP signature
------------------------------------------------------------------------------ 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
