Re: A base64 library?

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2024-03-19 18:48:33

On Tue, Mar 19, 2024 at 11:35 AM René Ferdinand Rivera Morell
<grafikrobot_at_[hidden]> wrote:
> Understood.. But having a generic API that models the reserved context
> independent of the encoding would allow composition of the encoder for
> url-target, query-target, host-target, etc.

Again the benefits are unclear. Creating a generic API is a tradeoff,
as it constrains a specific implementation into meeting the
requirements of the generic API. This might be ok if all the
implementations are largely the same but that becomes less and less
true as you add more encodings and especially decodings.

For example, the API for an encoder that supports streaming is going
to be necessarily different from one that does not support streaming.
Trying to abstract the "streaming" feature of the encoder will be an
exercise in futility (as I know from experience). The implementation
is also going to be different between them, with different performance
profiles.

The implementation for a decoder which can assume the output buffer
has sufficient size looks radically different than when it has to
handle the potential for insufficient space. The API also looks
different as in how the "insufficient space" condition is
communication. Trying to make this generic, is also going to be weird.

There are actually two problems proposed here:

1. High-quality implementations of numerical radix conversions (I
leave out character encodings since those are really a completely
different thing)

2. Designing a generic API for parameterizing radix conversions

There is a clear need for 1, but there is little evidence that a
Boost-quality solution for 2 exists.

A quick search shows no shortage of implementations (that is,
solutions to number 1 above) for a pretty good number of different
bases. If you believe that a workable generic API exists for encoding
and decoding, that is a separate problem that can be approached in
terms of design. And you can explore that by downloading and using the
already-existing, non-Boost libraries which perform radix conversions
and adapt them to your prototyped API.

FYI, I have explored the design space of "generic APIs for radix
conversions" and those experiments didn't go well. Maybe someone else
can show me how it's done...but it seems like the more generic you
make the interface the less opportunity you have for something that is
optimized for a particular base (like 64 as we are contemplating).

Thanks