As some of you may recall, I've been looking into implementing a non-Handle approach to persistent identifiers in our local version of DSpace. My approach has been to replace HandleManager bodily. So far I've gotten it to the point where it has the same functionality as out-of-the-box DSpace; that is, the handles don't work when accessed as external identifiers, but a manual substitution of the URL base produces a working URL.
Each time I blow away DSpace (as often happens during early stages of code development), I've noticed that the ID's start over from 1. It looks to me as if the HandleManager doesn't provide a strong guarantee of uniqueness; if DSpace is totally reinitialized, old Handles may be recycled. If this happened in a production environment, Handles for obsolete objects could point to the wrong object, rather than failing to resolve as they should. This makes me think that for our environment, which stresses the "unique" in URN's, I need to add a stronger guarantee of uniqueness. It also seems like a minor bug in DSpace. Have I missed anything? Does something come into play when a live handle server is used, which provides a stronger guarantee of uniqueness? I'm aware, by the way, that DSpace 1.6 has totally new code for non-Handle persistent identifiers. Our schedule doesn't let us wait. Don't blame me, I'm only the programmer. :) -- Gary McGath Digital Library Software Engineer Harvard University Library Office for Information Systems http://hul.harvard.edu/~gary/index.html ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
