1# TODO
2
3cppcodec is in pretty good shape already.
4Here are a number of things I'd like to do still:
5
6* Stuff in the GitHub issues list.
7
8* Implement place-based single number codecs (as opposed to stream codecs) that
9  view the entire input string as a single number and therefore zero-extend
10  *to the left* to the next bit multiple (e.g. n*5 for base32, n*4 for hex).
11  We want this to implement odd hex decoding (e.g. 0xF rather than 0x0F) and
12  the other interpretation of Crockford base32. No use case seems to exist for
13  base64 because it's thankfully specified well enough to always encode
14  octet streams, not numbers.
15  * API idea: Specialize the encode(Result&, const T&) overload to for T = number
16    and use that to accept numbers without changing the interface. Not sure if
17    it's a good idea to switch to a place-based single number codec based on T.
18  * API idea: Instead of trying to fit both into the same interface, make a
19    separate interface just for numbers. No binary arrays, templates only on
20    the encoded side.
21  * Naming: Current plan is to name place-based single number variants as the
22    original variant name plus `_num` appended. Examples: `base32_crockford_num`,
23    `hex_upper_num`, `hex_lower_num`.
24  * Since we don't know the total number of symbols (could be ignored characters?)
25    we might have to **(a)** assume there is no whitespace (fail) or
26    **(b)** walk the source data twice, the first time for counting symbols and
27    the second time for putting them into their right spot in the byte.
28
29* Investigate binary size considerations. See how well inline deduplication
30  works in popular linkers. I've had good experiences with boost::asio but
31  I don't know if those can translate to a codec library.
32
33* See if binary size would be saved if std::vector<[unsigned] char> could
34  return a temporary raw_result_buffer instead of being passed down as itself,
35  for use cases where both std::vector and raw pointer calls are in use.
36
37* Benchmark our performance against other libraries. We should be pretty fast
38  since cppcodec is avoiding unnecessary copies or object construction, but
39  we're also not doing any special vectorization or inline assembly. Plus it
40  would be nice to know that the compiler optimizes the inline function calls
41  well, instead of merely assuming it.
42
43* More codec variants:
44  * binary - useful for debugging
45  * octal
46  * z-base32 might be interesting (and has some funky marginal-space-savings
47    options if your input length isn't octets), but doesn't appear any more
48    popular than Crockford base32. Pretty far down on the list.
49  * base64 variants from PEM (RFC 1421), MIME (RFC 2045) and UTF-7 (RFC 2152)
50    since they're popular and less strict than RFC 4648. Requires more
51    sophisticated generation of whitespace and ideally also checks whether
52    the whitespace is correctly located in the input string.
53  * Proquints? I'm not quite sure about how useful those are in real life.
54
55* Checksums: Crockford base32 and RFC 6920 unpadded base64url define optional
56  checksums, OpenPGP base64 has a mandatory one. Supporting these would mean
57  a change to the API, potentially together with other options (but not
58  necessarily so).
59
60* User options: I'm not too big on accepting invalid/non-conformant input,
61  but maybe somebody has a valid use case where they need to be more lenient
62  than one of the standards where the solution shouldn't be a new codec variant
63  but instead options for an existing variant? I'm not convinced that's a good
64  idea right now, but if you think it is then please make a point.
65  * We'll probably want some kind of unspecified whitespace acceptance for hex,
66    maybe there should just be a template version of cppcodec::hex for that
67    with ignored characters as the template.
68  * Crockford base32 allows hyphens as visual delimiter (ignored when decoding)
69    but doesn't specify
70