On 02/17/2016 10:29 AM, Amos Jeffries wrote: > On 18/02/2016 5:59 a.m., William Lima wrote: >>> the other uses Redis for certificate caches.
>> A polished version of this would be a very welcomed addition for busy >> bumping proxies IMO! >> >> AFAICT, this polishing would require generalizing Ssl::CertificateDb >> into a base class providing open/get/put/close API to ssl_crtd and >> containing any code common to the supported db flavors. Two >> Ssl::CertificateDb kids would then cover the two known flavors: >> >> * OpenSslDb: The current clunky on-disk OpenSSL cache (available if >> ssl_crtd was built with OpenSSL headers/library); >> >> * RedisDb: A shiny Redis database client (available if ssl_crtd was >> built with Redis headers/library). >> >> The selection between the two kids will be determined, in part, by a >> command line option. > FYI: the model we have for helpers is that each backend type is > represented by a different helper binary that end-users configure to be > used (or not). It is not clear where a helper configuration ends and "backend type" begin. IMHO, it is better to have * a single helper that may be configured to use one of the two caching modes (with reasonable defaults making that customization optional!) than * two helpers, each supporting only one caching mode (requiring the admin to always explicitly pick the right helper!). > The OpenSSL local filesystem one is now called "security_file_certgen". > A Redis DB helper would be "security_redis_certgen". Why create a whole new binary? > Being able to build or omit helpers based on what the final environment > contains is important for our redistributors and portability. This is not about building or omitting a helper AFAICT. It is about what the helper does. Why not control that via a command line option, with good defaults (among other things such as ./configure tests)? Cheers, Alex. _______________________________________________ squid-dev mailing list [email protected] http://lists.squid-cache.org/listinfo/squid-dev
