On Fri, Jul 27, 2007 at 12:20:55AM -0400, Ekaterina Pechekhonova wrote: > I meant to say that building a flexible ExternalIdentifier service is a > challenging task (as James himself has said), so I am concerned that at > some point the configuration options will be dropped (because of lack of > time, etc.) and the bitstream identifier assignment will be "turned on" and > difficult to disable. > > This is less likely to happen if, instead of one ExternalIdentifier > implementation, Dspace will have a mechanism to plug-in different > implementations (and the default implementation will replicate current > functionality)
I have actually already done this. What I'm having trouble with is working through the code and figuring out what to use now where DSpace used to use "Handles" (ie: strings of various forms). It is much more appropriate in most of these places to use internal identifiers, and in the places where this information is exposed externally (eg OAI-PMH), we need to figure out how best to "fall back" if no external identifiers are available, and to make this mechanism consistent throughout the application. I should emphasise that (in my opinion) I've done the "hard bit"; now we need to decide what on earth to do with it. I can't follow the model that is currently employed both because it is broken, and because it no longer applies. I would like to see some kind of "identifier task force" emerge post 1.5 to properly sort this out before the 1.6 release when I hope to include it. The discussions on the mailing lists have been informative, but they don't get code written ;) cheers, Jim -- James Rutherford | Hewlett-Packard Limited registered Office: Research Engineer | Cain Road, HP Labs | Bracknell, Bristol, UK | Berks +44 117 312 7066 | RG12 1HN. [EMAIL PROTECTED] | Registered No: 690597 England The contents of this message and any attachments to it are confidential and may be legally privileged. If you have received this message in error, you should delete it from your system immediately and advise the sender. To any recipient of this message within HP, unless otherwise stated you should consider this message and attachments as "HP CONFIDENTIAL". ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
