[squid-dev] Care and feeding of ConnStateData

[Alex Rousskov]

On 07/08/2016 08:20 PM, Amos Jeffries wrote:
> On 9/07/2016 6:19 a.m., Alex Rousskov wrote:
>> On 07/07/2016 04:16 PM, Amos Jeffries wrote:

>>> Whichever way we go what the ::Server needs is:

>> ... Snipped to avoid discussing complex design issues irrelevant for
>> this thread. I agree with some of the items you listed, but not
>> necessarily all of it, and there may be missing items...


> If you are going to throw away the technical details about what needs to
> stay and what needs to go. Then we have reached a deadlock again.

I am throwing away nothing. I am simply ignoring IMO irrelevant (and
probably controversial!) stuff so that we can fix a specific problem and
make progress. I am happy to discuss your list later/separately!

You believe that we need to answer some additional questions now, before
we can solve the problem at hand, but you have _not_ demonstrated why
those questions are important for solving the problem. The burden of
proving relevance is on you, not me, because I have already presented
more than enough specific, indisputable evidence that the problem exists
today and proposed a simple fix/solution without known significant flaws.


The exact list of features to be removed from the future Server is
irrelevant to removing the current split of the class. The existence of
that split is the problem at hand. The details of misplaced code
currently on one side of that split are irrelevant because we do agree
that at least _some_ non-trivial code currently in ConnStateData belongs
elsewhere, and that it will take quite some time to get it out of
ConnStateData correctly. [ Well, at least I hope we agree on that -- it
seems obvious to me, and nothing you have said indicates the opposite
opinion AFAICT. ]

In other words, we seem to agree that it is impossible to get rid of
ConnStateData tomorrow. Thus, the painful split will persist for quite
some time unless we remove it. Removing that split today is easy,
improves the current Squid code, helps some pending working code, and
does not significantly inconvenience any other pending working code
either. Removing that painful split today is a simple solution, and you
have provided no alternative solution and found no significant flaws in
the proposed one AFAICT.


For example:

* We might disagree whether the future Server would know about the
SslBump feature. However, regardless of where we eventually place
SslBump, the current class split can be removed. The two issues are
orthogonal.

* Similarly, we might disagree whether the future Server would know
about the PROXY protocol. However, regardless of where we eventually
place that PROXY handling code, the current class split can be removed.
The two issues are orthogonal.


> We are planning how to go from a tangled ConnStateData to a clean and
> documented ::Server. 

Currently, the issue being discussed here is much narrower -- we are
just trying to solve the problems introduced by the premature
ConnStateData split into two classes.


> It is very important that we know and agree on what
> the goal looks like before we try arguing approaches to get there.

AFAICT, we agree on enough about that future to solve the problem at
hand. The stuff we may disagree on can be discussed afterwards (or even
in parallel).

Alex.