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. _______________________________________________ squid-dev mailing list [email protected] http://lists.squid-cache.org/listinfo/squid-dev
