[squid-dev] Drop cache_object protocol support

[Alex Rousskov]

On 1/26/23 04:12, Amos Jeffries wrote:
> On 26/01/2023 3:30 am, Alex Rousskov wrote:
>> On 1/25/23 07:29, Amos Jeffries wrote:
>>> On 25/01/2023 5:34 pm, Alex Rousskov wrote:
>>>> IMO, we should not keep any code that is only needed for Squid v3.1 
>>>> and earlier. Squid v3.2 and later should http-based cache manager 
>>>> access, right? More code always means more maintenance overheads and 
>>>> higher change costs. Given our lack of resources, we should start 
>>>> ignoring Squid v3 needs.
>>>
>>> In sentiment I agree. In practicality we have to cope with "LTS" from 
>>> vendors, and Squid bugs in the manager.
>>
>> IMO, LTS vendors and old Squid bugs do not prevent us from removing 
>> cache_object support from cachemgr.cgi: The number of admins that 
>> match _all_ of the conditions listed below at the same time is 
>> negligible.

> Evidence needed.

It would be nice to back up my reasoning with hard evidence, but I do 
not think it is _required_ in this case. It is impractical to prove 
negligibly low count of X when there is no way to enumerate all 
instances where X might exist. These kind of decisions require a 
judgement call.

Circumstantial evidence does exist -- the Project does not see a 
constant stream of complaints, bug reports, and improvements related to 
cachemgr.cgi despite its many shortcomings. We also do not see a lot of 
complaints about v3.2 or a lot of examples where v3 users cannot 
upgrade. To avoid misunderstanding, I am not claiming that evidence 
proves my point beyond reasonable doubt. It is only partial and 
circumstantial.


>> We should not spend our resources "coping" with those esoteric cases.
>>
>> 1. Use Squid v3.
>> 2. Use Squid v7.
>> 3. Use cachemgr.cgi to manage both Squid versions.
>> 4. Cannot use cachemgr.cgi from Squid v6.
>> 5. Cannot patch cachemgr.cgi v7 to restore cache_object support.
> 
> Declaring groups of users "negligible" or "esoteric" without evidence 
> just to push your preferred decision is not a valid line of argument.

First of all, I am not declaring groups of users "negligible" or 
"esoteric". I am speculating about the number of certain use cases and 
classifying those use cases.

I believe my line of argument is valid, even though it is not (and, 
given existing Project limitations, cannot be) backed by hard evidence. 
We will never know how many use cases match all 5 criteria. In fact, we 
will never know how many Squid use cases are out there today!

If you have hard evidence that illustrates that relevant use cases are 
common, please present it. Needless to say, I am not aware of such evidence.


>>> v3.2 has http: but the https:, ftp:, whois:, gopher: schemes were 
>>> broken until late in the v3.5 series backports.
>>> So going by [1] LTS systems still using v3.2 are still a pain.
>>
>> We can stop that pain any time we want. All it takes is for us to stop 
>> mentioning v3 releases when making design decisions like this one. We 
>> _choose_ to prolong that pain and to spend scarce resources on a 
>> negligible percentage of unimportant use cases instead of spending 
>> those resources on popular and important use cases.

> We are making decisions which affect other peoples lives and employment. 
> The "pain" I have been mentioning is _their_ pain, not ours.

When making a decision, we should take into account the "lives and 
employment" and "pains" of all affected people. We cannot make everybody 
happy, and if we try, we are likely to increase the overall level of 
unhappiness. Making (few) v3 users happier at the expense of hurting 
(many more) v5 users is the wrong balance IMO, and that is what we often 
end up doing when it comes to this kind of decisions.


> It is appropriate to keep the human aspect in mind for this decision and 
> utilize the data we do have available.

Agreed. That is exactly what I am doing.


> That data I have says v3.2 and v3.5 are still relevant factors for this 
> change.

Their relevance is not being disputed. What we disagree on is whether 
those (real) v3 user needs are enough to hurt other (also real) users.


>>> The longer we wait on removal from the CGI and CLI tools (only) the 
>>> more seamless it goes. So I am inclined to be very conservative on 
>>> the tools capability removal and proactive on ensuring they can cope 
>>> with the squid capability loss.
>>
>> And since there is no way to actually measure "more seamless" or to 
>> prove that we are wasting resources on rare unimportant use cases, we 
>> end up doing what we do best -- increasing and prolonging pain.
>>
> 
> We do have at least one measure. I use the count of Vendors distributing 
> each problematic release.
> Over time their old versions reach EOL, or LTS get updated to new Squid 
> versions etc.
> We can reasonably expect admin to be using a currently supported version 
> of their OS packages.

The proposed measure is just too coarse to be applicable here because 
the proposal does _not_ inconvenience users of problematic releases. In 
fact, the proposal does _not_  inconvenience users of _any_ given Squid 
release in existence! It only inconvenience users that match a long list 
of very special criteria. For example, it requires a user to use _both_ 
v3 and v7 releases, at the same time.

Alex.