On Mon, Jul 24, 2017 at 8:09 AM, Richard Hodges via Boost wrote:

Yes. I'm shocked if it doesn't already have one.

What are the expectations from a library claiming the moniker "Boost.Base64?" Does it support just radix=64? Or is it a general purpose library that works with any radix and a user-supplied alphabet? If the latter is it limited to using integral types or does it work with multiprecision integers? Does it use std::string? Fixed size buffers? Does it work with Allocators? Which base-64 alphabets does it support? MIME? UTF-7? RFC3548? RFC4648? Does it support url-encoding and decoding i.e. ("modified Base64 for URL")? Please be specific in the type of base64 library you are proposing. Thanks

On Mon, Jul 24, 2017 at 8:24 AM, Greger via Boost wrote:

Here is some documentation:

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

Thank you. From the docs, I see these signatures: std::string base64_encode (const char *buf, int len); std::string base64_decode (const char *buf, int len); 1. How are errors communicated? 2. How does the caller specify the Allocator to use? 3. Are there routines to operate on fixed-size buffers (no allocation)? I also see this note:

It is available for a moderate compensation. Let me know by email and I will send you the source.

On 24/07/17 16:28, Vinnie Falco via Boost wrote:

On Mon, Jul 24, 2017 at 8:27 AM, Vinnie Falco wrote:

...

On Mon, Jul 24, 2017 at 8:24 AM, Greger via Boost wrote: I also see this note:

...

It is available for a moderate compensation. Let me know by email and I will send you the source.

Is this library open source or commercial in nature? What license is it furnished under? Also, how is this better than the numerous other base64 libraries (which are free) such as this one:

http://renenyffenegger.ch/notes/development/Base64/Encoding-and-decoding-bas...

Or https://github.com/ome/ome-common-cpp/blob/master/lib/ome/common/base64.h which I probably wrote based on a similar source when I realised the Boost base64 support was broken and needed a quick implementation. It avoids allocation issues by allowing the use of iterators including back_inserter. 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...). 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? Regards, Roger

On Mon, Jul 24, 2017 at 9:54 AM, Roger Leigh via Boost 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...). 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.

Thanks

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost I don't really know what to say. The lib was created (perhaps) 7-8 years ago when I needed C/C++ functions to do the job with the requirement to be compatible to PHP's corresponding routines. And the version I have now does exactly that. It has not been 'released' ever. What conserns

On 24.07.2017 20:02, Vinnie Falco via Boost wrote: license then I'm not a lawyer, money is funny but not strictly a requirement. Considering that the lib was created on a debian linux workstation using open source tools, then it should probably be open source as well. Greg

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 wrote:

...

On Mon, Jul 24, 2017 at 9:54 AM, Roger Leigh via Boost 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...). 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

On 7/24/17 9:54 AM, Roger Leigh via Boost wrote:

On 24/07/17 16:28, Vinnie Falco via Boost wrote:

...

On Mon, Jul 24, 2017 at 8:27 AM, Vinnie Falco wrote:

...

On Mon, Jul 24, 2017 at 8:24 AM, Greger via Boost wrote: I also see this note:

...

It is available for a moderate compensation. Let me know by email and I will send you the source.

Is this library open source or commercial in nature? What license is it furnished under? Also, how is this better than the numerous other base64 libraries (which are free) such as this one:

http://renenyffenegger.ch/notes/development/Base64/Encoding-and-decoding-bas...

Or https://github.com/ome/ome-common-cpp/blob/master/lib/ome/common/base64.h

which I probably wrote based on a similar source when I realised the Boost base64 support was broken and needed a quick implementation. It avoids allocation issues by allowing the use of iterators including back_inserter.

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...). 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'm guessing it would be pretty easy to fix. I base this on the design which is built up as a stack of iterator pairs. This is documented in the serialization library under http://www.boost.org/doc/libs/1_64_0/libs/serialization/doc/dataflow.html This is used for the base64 stuff in the serialization library which as far as I know is correct. That doesn't include adding on padding at the end - which maybe it should. In any case making a stand along base64 component would require understanding the issues, making a small variation on the one in the library, make a test and adding it the test suite and making a commitment to support it in the future. I just haven't had the motivation to do that - even though I think the code and design are very convenient and flexible. Result is decent performance as well. FYI it was made before boost ranges and can be considered a demonstration of the validity of using the range idea. Robert Ramey

Regards, Roger

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Thank's, useful link G On 15.8.2017 14:45, Bjorn Reese via Boost wrote:

On 07/24/2017 07:02 PM, Vinnie Falco via Boost wrote:

...

* Variations such as rfc3548, rfc, 4648, modified Base64 for URL

And https://en.wikipedia.org/wiki/Binary-to-text_encoding

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

--- Avast Antivirus on tarkistanut tämän sähköpostin virusten varalta. https://www.avast.com/antivirus