fixed suggested encoding

This commit is contained in:
Ilya_Shlyakhter 2018-09-26 18:11:35 +00:00 committed by admin
parent a5ede1f283
commit acfc49ae6e

View file

@ -1,4 +1,4 @@
The link targets of annexed files are currently very long. This creates problems e.g. when browsing directories in Emacs (I mostly work through a text terminal). Ideally, the key would not be repeated twice in the link, but I understand this is hard to do compatibly. Maybe, the following simpler alternative could be implemented? Key checksums are currently represented in base16 using only the characters 0-9a-f . The same information could be represented with shorter strings using base64 or other encoding, where a larger range of chars is used. So for each backend you'd add a corresponding one that does the same thing, but encodes the checksum part of the key with shorter strings.
The link targets of annexed files are currently very long. This creates problems e.g. when browsing directories in Emacs (I mostly work through a text terminal). Ideally, the key would not be repeated twice in the link, but I understand this is hard to do compatibly. Maybe, the following simpler alternative could be implemented? Key checksums are currently represented in base16 using only the characters 0-9a-f . The same information could be represented with shorter strings using base64url or other encoding, where a larger range of chars is used. So for each backend you'd add a corresponding one that does the same thing, but encodes the checksum part of the key with shorter strings.
Or, if you're tired of backend requests, maybe implement a scheme for external backends, like the one for external special remotes? For external backend EXTNNN the user would put a script git-annex-external-backend-NNN in the path; the script would support commands like calckey, examinekey . Then I could also implement e.g. canonicalizing backends that strip away variable but semantically irrelevant information before computing the checksum.