On 04/23/2014 05:36 AM, Amos Jeffries wrote: > So, > The internals of the library code (when enabled) can reference OpenSSL > and/or the src/ssl/*.h objects as needed.
I am not sure that is a good rule. Maintaining an interface-level separation of OpenSSL-reliant code from all other code would be better than sprinkling common code with #ifdefs because #ifdefs inside a method do not provide a good separation boundary. If possible, we should restrict security/* to OpenSSL/GnuTLS-neutral code IMO. > If this is getting too complicated or confusing, please fee free to just > commit what you have and I am happy to followup with the shuffling. I think this should be committed as is, we need to agree on security/* composition rules, and then the shuffling can start. The final security/* design should not be too complicated or confusing, but it is not fully thought through yet IMO. The difficult work on providing an OpenSSL-neutral API is already done so that part would be easy to move. If we decide that security/ can be polluted with OpenSSL-specific code, the rest can be moved as easily. If we decide against that, more serious changes would be required for that move to happen. Cheers, Alex.
