Re: Proposal: switch to always-build for some currently optional features

On 20/09/22 01:28, Francesco Chemolli wrote:
> Hi all,
>     there is a bunch of features that are currently gated at compile 
> time: among others, I see:
> - adaptation (icap, ecap)
> - authentication
> - ident
> - delay pools
> - cache digests
> - htcp
> - cache digests
> - wccp
> - unlinkd
> 
> I'd like to propose that we switch to always-build them.


If you mean switching their build to default-enable. Sure - but there 
are often good reasons for each specific item to be default disabled today:

  * performance expensive logic
    delay pools, cache digests, adaptation

  * unavailable dependencies
   adaptation, auth sub-components

  * rarely necessary
   unlinkd, wccp, delay pools, htcp

  * buggy
   delay pools, wccp

Those reasons are also why we cannot simply remove the ./configure 
options for them (yet).


> We would gain:
> - code clarity

This proposal only has a very minor gain for code clarity. The worst of 
that problem is all the #if/def looking for OS hacks/workarounds, and 
the unnecessary custom re-implementations still hanging around.


> - ease of development

I do no think there will be any change regarding ease. Just a different 
way of setting up the testing.


> - test coverage

Disagree. The default/min/max build test "layers" already build as many 
of these as can be tested.

Plus all the reasons Alex already stated.

> - feature uniformity across builds
> 

I agree with most of Alex points on these.

In addition, on the security side there are some passive defense 
benefits from feature obscurity and avoidance of a mono-culture for 
Squid installations.



> We would lose:
> - slightly longer build time


Longer build time may not be an issue for users not building Squid 
often. But it would be compounding the already tough build farm situation.


> - larger binaries
> 
> The latter should not be an issue anymore, even the most embedded of 
> embedded systems Squid is likely to be used on has plenty of storage and 
> core, and the former should not be too big a deal
> 

It has been 4-5 years since I had any direct customers needing embedded 
Squid. AIUI the needs there are for software updates on hardware that 
are difficult to change (eg satellites or remote geographic outposts).



HTH
Amos
_______________________________________________
squid-dev mailing list
[email protected]
http://lists.squid-cache.org/listinfo/squid-dev