Re: [boost] base64?

Subject: Re: [boost] base64?
From: Greger (ggh_at_[hidden])
Date: 2017-07-27 11:41:53

On 27.07.2017 12:40, Olaf van der Spek via Boost wrote:
> On Mon, Jul 24, 2017 at 7:02 PM, Vinnie Falco via Boost
> <boost_at_[hidden]> wrote:
>> On Mon, Jul 24, 2017 at 9:54 AM, Roger Leigh via Boost
>> <boost_at_[hidden]> wrote:
>>> We already have base64 conversion in boost/archive/iterators/*base64*.hpp.
>>> It works but screws up the whitespace
>>> (https://stackoverflow.com/questions/10521581/base64-encode-using-boost-throw-exception/10973348#10973348).
>>> It's a shame the various adapters don't work properly together; is there any
>>> prospect of this being fixed, or is the existing design simply too
>>> inflexible to make a proper base64 implementation?
>> I think a good base64 implementation would be an excellent subject for
>> GSoC or someone who wants to participate in Boost we would just have
>> to clearly define the things we want from it:
>>
>> * Caller provided buffers
>> * Allocator awareness
>> * Flexible types of input
>> * Choice of alphabet
>> * Choice of radix?
>> * Option for line-widths / newlines
>> * Iterator based interface
>> * Variations such as rfc3548, rfc, 4648, modified Base64 for URL
>>
>> Could be called Boost.Radix
>>
>> I know such a library would be immensely useful to a higher-level
>> library which tries to address some of those "out-of-scope" items in
>> Beast. Base-64 and other radix encodings come up often in HTTP field
>> values and uri targets, as well as in the body of certain message
>> types.
>>
>> If anyone is interested I wouldn't mind getting together on Google
>> Hangouts with a https://kobra.io/#/ shared document and hammering out
>> a prototype set of declarations, which someone else could implement.
> Why not do it on this list?
>
> I'd love to see base64 support too.
>
>
The code is here:

http://www.multi.fi/~ghaga/base64docs/html/index.html

as created on a debian linux workstation with open source tools the 
license becomes open source as well.

Constructive criticism and suggestions are welcome.

ty,
Greg