[squid-dev] Patches proposal

[Alex Rousskov]

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.