Re: A base64 library?

From: René Ferdinand Rivera Morell (grafikrobot_at_[hidden])
Date: 2024-03-19 18:35:14

On Tue, Mar 19, 2024 at 1:26 PM Vinnie Falco <vinnie.falco_at_[hidden]> wrote:
>
> On Tue, Mar 19, 2024 at 11:17 AM René Ferdinand Rivera Morell via
> Boost <boost_at_[hidden]> wrote:
> > Yes, but.. I would like a library that handles various types of
> > encoding/decoding with the "same" interface.
> > ...
> > url
> > ...
>
> Hmm.... I disagree. There are often unique qualities of an encoding
> that complicate creating a generic API. For example, with
> URL-encoding, there is the concept of the "reserved set." That is, the
> set of characters for which escaping is required. Different parts of a
> URL have different reserved sets. The target for example reserves the
> forward slash (among other things). The query reserves the hashtag '#'
> but not the forward slash.
>
> On the other hand base64 has no concept of reserved sets as it
> operates on unsigned integers of arbitrary bit width. One is a numeric
> encoding, the other is a character encoding.

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.

> > If it's more than base-64, yes, it could be a Boost library.
>
> It isn't clear why only offering base-64 functionality is
> insufficient. In fact, as a proponent of "modular boost" surely you
> see value in isolating each radix to its own library.

Yes :-) But I was also thinking that a user is more likely to use a
library if it overcomes the download "cost". If it's just base64 they
are more likely to either write their own (by copy-pasting from
somewhere) or use some single header standalone library instead of
reaching for the Boost solution.

-- 
-- René Ferdinand Rivera Morell
-- Don't Assume Anything  -- No Supone Nada
-- Robot Dreams - http://robot-dreams.net