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.
>
>
Received on Wed Apr 23 2014 - 16:42:50 MDT
This archive was generated by hypermail 2.2.0 : Wed Apr 23 2014 - 12:00:13 MDT