Hi Is anyone interested in a base64 encode/decode library (for boost)? ty Greger
Yes. I'm shocked if it doesn't already have one. On Mon, 24 Jul 2017 at 17:08, Greger via Boost <boost@lists.boost.org> wrote:
Hi
Is anyone interested in a base64 encode/decode library (for boost)?
ty
Greger
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mon, Jul 24, 2017 at 8:09 AM, Richard Hodges via Boost <boost@lists.boost.org> 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
Here is some documentation: http://www.multi.fi/~ghaga/base64docs/html/index.html br Greg On 24.7.2017 18:14, Vinnie Falco 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
On Mon, Jul 24, 2017 at 8:09 AM, Richard Hodges via Boost <boost@lists.boost.org> wrote: 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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mon, Jul 24, 2017 at 8:24 AM, Greger via Boost <boost@lists.boost.org> wrote:
Here is some documentation:
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 Mon, Jul 24, 2017 at 8:27 AM, Vinnie Falco <vinnie.falco@gmail.com> wrote:
On Mon, Jul 24, 2017 at 8:24 AM, Greger via Boost <boost@lists.boost.org> 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-base-64-with-cpp> Thanks
On 24/07/17 16:28, Vinnie Falco via Boost wrote:
On Mon, Jul 24, 2017 at 8:27 AM, Vinnie Falco <vinnie.falco@gmail.com> wrote:
On Mon, Jul 24, 2017 at 8:24 AM, Greger via Boost <boost@lists.boost.org> 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-base-64-with-cpp>
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 <boost@lists.boost.org> 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
On Mon, Jul 24, 2017 at 9:54 AM, Roger Leigh via Boost <boost@lists.boost.org> 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 Mon, Jul 24, 2017 at 7:02 PM, Vinnie Falco via Boost <boost@lists.boost.org> wrote:
On Mon, Jul 24, 2017 at 9:54 AM, Roger Leigh via Boost <boost@lists.boost.org> 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. -- Olaf
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@lists.boost.org> wrote:
On Mon, Jul 24, 2017 at 9:54 AM, Roger Leigh via Boost <boost@lists.boost.org> 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 27 July 2017 at 14:41, Greger via Boost <boost@lists.boost.org> wrote:
as created on a debian linux workstation with open source tools the license becomes open source as well.
Really? Doesn't it depend only on what you would like it [the license] to be and how much money you would like to have [per whatever]? Constructive criticism and suggestions are welcome.
Untill you license your achievement under the BSL license <http://www.boost.org/LICENSE_1_0.txt>, you won't find many people interested on this ML (and even then). Good luck. degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798
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 <vinnie.falco@gmail.com> wrote:
On Mon, Jul 24, 2017 at 8:24 AM, Greger via Boost <boost@lists.boost.org> 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-base-64-with-cpp>
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
On 07/24/2017 07:02 PM, Vinnie Falco via Boost wrote:
* Variations such as rfc3548, rfc, 4648, modified Base64 for URL
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
On 07/24/17 18:24, Greger via Boost wrote:
Here is some documentation:
The interface documented there does not account for the possibility that the original data may not be a string (of characters). My requirements to a Base64 libraries would be: - The library should be able to work with any binary data. - It should be able to produce encoded/decoded data in a user-supplied storage. - I would like to be able to supply custom character conversion rules and possibly disable trailing padding so that different variants of Base64 (e.g. [1]) can be implemented. - The library should be fast. [1]: https://tools.ietf.org/html/rfc4648#section-5
participants (9)
-
Andrey Semashev -
Bjorn Reese -
degski -
Greger -
Olaf van der Spek -
Richard Hodges -
Robert Ramey -
Roger Leigh -
Vinnie Falco