https://sourceware.org/bugzilla/show_bug.cgi?id=32003
--- Comment #27 from Benjamin Drung <bdrung at posteo dot de> ---
Taking all comments into account, here is my implementation proposals:
Encoding schema
===============
Option 1: Support percent-encoding of the JSON data. Percent-encoding is widely
used and supported (for example, Python provides urllib.parse.unquote for
decoding and urllib.parse.quote for encoding). Example encoded JSON:
'{%22foo%22:%22bar%22}' or '%7B%22foo%22%3A%22bar%22%7D'
This option has the benefit of being easy to implement. Either the encoded
string can be read directly (I can spot package names and version in there) or
decoded using Python's urllib.parse.unquote or online tools.
Option 2: Support percent-encoding and %[string] (where string refers to the
name in HTML's Named Character References) the JSON data. Example encoded JSON:
'{%[quot]foo%[quot]:%[quot]bar%[quot]}' or '{%22foo%22:%22bar%22}'
This option allow people to use %[string] encoding in case they dislike
percent-encoding. The drawback is that it is more work to implement since there
must be a list of names. To make the code simpler, the list of allowed names
might be restricted to, e. g. quot, comma, lbrace, rbrace and maybe add space.
These are the two options that I would be happy about to implement. Supporting
only %[string] would not satisfy me. Using base64 encoding would make the
string shorter, but would not be human readable. Quoted-printable would be an
alternative, but the problematic characters like comma and quotes would not be
encoded by quoted-printable.
Parameter usage
===============
Option A: Introduce a new --encoded-package-metadata parameter that takes the
encoded string.
Option B: Extend --package-metadata to always decode the given string. As
previously discussed, package names and version should not contain percent
characters. So this change should not break backward compatibility.
Which of those proposals do you want to see implemented? My initial
implementation is option 1A.
--
You are receiving this mail because:
You are on the CC list for the bug.
