Currently the code used to check the CRL status is quite heavy and uses a rather large memory footprint depending on the SSL provider. In future versions it may be beneficial to abstract the CRL testing out of the SSL class and into the downloader.
It'd be nice if the SSL class itself was more of a getter of protected attributes than a getter of raw data and processing of meta data. Right now having the CRL code all within the SSL Cert class makes things feel dense. I think there may be some mixed concerns as well that might benefit from a refactor.
Currently the code used to check the CRL status is quite heavy and uses a rather large memory footprint depending on the SSL provider. In future versions it may be beneficial to abstract the CRL testing out of the SSL class and into the downloader.
It'd be nice if the SSL class itself was more of a getter of protected attributes than a getter of raw data and processing of meta data. Right now having the CRL code all within the SSL Cert class makes things feel dense. I think there may be some mixed concerns as well that might benefit from a refactor.