4831c3328c
Current thought is to organize this by: - Core SSL_CTX APIs (creating, destroying) - Core SSL APIs (creating destroying, maybe handshake, read, write as well) - APIs to configure SSL_CTX/SSL, roughly grouped by feature. Probably options and modes are the first two sections. SSL_TXT_* constants can be part of documenting cipher suite configuration. - APIs to query state from SSL_CTX/SSL, roughly grouped by feature. (Or perhaps these should be folded into the configuration sections?) The functions themselves aren't reordered or reorganized to match the eventual header order yet. Though I did do the s -> ssl rename on the ones I've touched. Also formally deprecate SSL_clear. It would be a core SSL API except it's horrible. Change-Id: Ia7e4fdcb7bad4e9ccdee8cf8c3136dc63aaaa772 Reviewed-on: https://boringssl-review.googlesource.com/4784 Reviewed-by: Adam Langley <agl@google.com> |
||
---|---|---|
.. | ||
openssl |