OK, if others see a use for persistent local identifiers then they had better be persistent. I wasn't thrilled with the idea of overloading database record IDs either, especially since we'd have to compound (ID, type) tuples into some string representation, to uniquely identify an object.
So, it sounds like what we want is to split the two ways that Handles are used. One use is as, er, Handles: globally unique persistent identifiers that mean something outside of the local instance. That should remain as it is. The other use is as locally-unique identifiers of DSOs regardless of type. For this purpose the prefix is rubbish; unless we have multiple prefixes for some reason, we only care about the suffix. If this use were separated from the Handle system entirely then it could be a simple incrementing numeric label. If we can pull these meanings apart, then someone who doesn't want Handles can, theoretically, unplug them from DSpace and never think about them again, while DSpace still has something it can use to uniquely identify things locally. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient.
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
