I mostly agree, but suggest you consider what happens when e.g. the LDAP entry goes away; we can't get rid of the EPerson because it's connected to some policy objects or something, and for forensics we'll want to be able to connect it with a real person. So, I suggest recording at least the personal name and perhaps treating it as a cache: if the identity-supplier comes up with a new value, update it, but don't delete it with the identity goes away. Then, you can tell that zombie EPerson used to be "Joe Sixpack".
Also, what about when the identity source is unavailable or slow? If the administrator is editing groups, do you want to wait for dozens of name queries for each page? The identity plugin could implement some caching too, but that won't help for the first pass through a long user list. I recommend profiling how this data is used, e.g. the subscription email service is going to call for a lot of users' email addresses (though it's a _good_ thing to get the current, accurate, value out of LDAP or whatever). Just consider performance and failure modes. Most of the other metadata, e.g. phone and email, aren't even worth caching since they would presumably be invalid if the identity source hasn't got them any more. There may still be some demand to allow fields that come from the identity plugin (e.g. personal name) to be locally modified, e.g. if someone doesn't like their name on LDAP but isn't allowed to change it there. -- Larry On May 12, 2009, at 3:03 PM, 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. > > 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. > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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
