On Sun, Jul 26, 2009 at 4:36 PM, Timothy Brownawell<tbrow...@prjek.net> wrote: > Is there any particular reason that we ACE-encode[1] the domain part > (after the '@') of key names on input, and then never decode them (the > only place that externalize_rsa_keypair_id() is ever called is when > writing _MTN/options)? I'm working on making certs link to keys by hash > instead of name, which seems like a perfect opportunity to also get rid > of this since the schema is changing anyway.
I recall asking Graydone this many moons ago and being told that it was basically historical junk. And around the same time I surveyed a bunch of monotone databases and couldn't find anything that wasn't plain ASCII. You've maybe got a bigger data set with your hosting service, though. In principle I would be glad to see all of that go. However, two cautions: We are getting Unicode normalization (to some schema or other) as a side effect. We maybe don't need that anymore if keys are indexed by fingerprint rather than human-readable name, but I would think carefully about the consequences of a visual collision for each thing-in-the-database that loses normalization. Also, we are using libidn as a wrapper around libiconv (via stringprep_convert) as well as for ACE, and we *need* (but don't have) better Unicode awareness in several areas (e.g. pathnames) that libidn might be able to help with -- I haven't looked at its full API though. zw _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel