On 04/23/2014 06:08 PM, Alex Rousskov wrote: > 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. >
OK. So, I will apply the patch as is, without moving the PeerConnector patch under "Security" namespace. Moving PeerConnector under the Security namespace and under the security directory is small work, so I think we will not have any problem, to make it later. Regards, Christos > > Cheers, > > Alex. > >
