For b., I think the solution is to have a configuration property to enable/disable identity encodings.
As for the encoding, I don't think hashCode is reasonable. The risk of collision is to high. And hashCode+equals might become overly expensive. I have today implemented an encoding where a bunch of characters are deemed "safe", and all chars not safe are transformed to an escaped sequence... I used ~ followed by four digit hex code of the character not whitelisted. It is reasonable, and as Paul suggests, I guess it is relatively easy to write a conversion script to upgrade a store. // Niclas On Tue, Jul 7, 2015 at 3:43 PM, Paul Merlin <[email protected]> wrote: > > > 1/ hash(identity) ? safe but may be costly > BUT, this makes FileES "harder" to use as identities are "hidden". > > > urlencode(identity) ? pretty ugly but safe > Can be ugly with special chars. > Will encode more that needed. > For many cases we still can easily read identities. > > -- Niclas Hedhman, Software Developer http://zest.apache.org - New Energy for Java
