Hello,
Does this mean you will be converting the source-code of Botan to Boost standards or you are going to wrap it?
1. If it is conversions two issues may rise: a) License Botan is licensed under BSD license with is different from Boost and all the code you will write for boost would not have correct license. b) Conversion to Boost means fork... How do you expect to synchronize changes in two libraries and most important security updates.
This means lots of work in the live cycle of Boost.Botan
I'll fork it, as stated in my proposal (which I sent sometime after the abstract). It'll be relicensed under BSL. As for synchronization, this will have to be done by hand (which I will do for some time).
Additional points:
- Botan uses GNU gmp library licensed under LGPL... Does it fit to Boost licensing guidelines?
It doesn't require gmp and is perfectly capable of working without it. It's available as a plugin, but a default implementation is already included.
- I think that you should be really specific what would be the advantage of using Boost.Botan library over original Botan one or OpenSSL that Boost.Asio uses.
Here are some: * Tighter integration with Boost (ASIO, and possibly iostreams) * Some functions are considerable faster (such as RSA, which the maintainer purports to be several times faster than OpenSSL. SHA-1 is SSE2 optimized). * There is plugin support for OpenSSL, so ASIO would be modified to use the plugin system (which would use the default implementation or OpenSSL).
You might want to consider adding some discussion to your proposal about the crypto library in the vault. What features are in the vault Crypto that might be useful? That aren't useful? Why do you feel that Botan is a better starting point.
The crypto library in the vault contains mostly hash algorithms, which Botan already contains (and some of them e.g. SHA-1 have a SSE optimized version). And Botan contains better documentation and testing. Also, Botan was engineered mostly by a security expert, meaning it is likely to be more secure. It is also being maintained, so security and feature patches will be made.
Your proposal is very ambitious! IMHO, that's not doable in full over the summer. If you trimmed it down into a more focused feature set (for instance replacing SSL in ASIO, or adding TLS to ASIO) it would give you a more realistic chance to finish what you are suggesting.
It is very ambitious! But as I say in my draft, it'll be done in two parts. I don't think that porting is unrealistic for the summer part of the project. Many thanks for the feedback, Chad Seibert _________________________________________________________________ The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multiaccount&ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_4