On 06/12/2014 03:01 AM, Amos Jeffries wrote: > On 12/06/2014 8:09 a.m., Alex Rousskov wrote: >> On 06/11/2014 05:15 AM, Amos Jeffries wrote: >>>>> On 06/10/2014 12:09 AM, Kinkie wrote: >>>> I had understood that it would eventually be a catch-all directive >>>> for all squid service ports (possibly including FTP etc). >> >>> That was indeed the long term intention. >> >> If the long-term plan is to replace all *_port option with a single >> "port" or "listen" option, then I would like to hear why we should do >> that. The analysis presented so far was specific to HTTP (including >> HTTPS) so it does not really apply any more. Needless to say, the end >> goal has significant influence on the new directive name and internal >> code design. > > Yes the only ports we have to backward-compat with this are the > http_port and https_port. No other port has separate TCP and TLS variants.
I do not understand what you are saying. Either you want to eventually convert all listening ports into a single directive with new options OR you want to eventually convert just the http_port and https_port directives into a single one with SSL/etc protocol as an option. Each alternative results in a rather different code design, directive name, etc. It is impossible to evaluate your proposal until it is clear what the intended end goal is. >> For example, why replacing http_port and snmp_port with "port http" and >> "port snmp" is better than having distinct protocol-specific directives >> for those two protocols? > > Today we have to configure (and explain to people): > > XY_port ... Y protocol=X > or > XY_port ... Y > or > X_port ... protocol=X > or > X_port ... Y > > NP: the *long-term* goals working towards is: > > port ... protocol=X > or > port ... Y protocol=X Today, protocol=X parameters mean something completely unrelated to this discussion AFAICT. They are not going to disappear regardless of how or whether we merge the existing *_port options. Thus, your example above does not clarify things, only confuse them further. The question is rather simple so I do not understand why we are avoiding a direct answer during this discussion: * Do you think we should eventually merge all existing *_port directives into one? If the answer is "yes", then, needless to say, we can still start with just the two http*_port directives while keeping the long-term goal in mind. If this flavor of the proposal is accepted, then the new directive will be called "port" or "listen", and there will be other effects on code, documentation, etc. If the answer is "no", then we need to know which existing directives you think should be eventually merged into one. What is the unifying criteria/principle in this case? A possible answer could be a common transfer protocol being HTTP. If this flavor of the proposal is accepted, then the new directive will be called "http_port" and there will be other effects on code, documentation, etc. > Today I am tryingto get rid of the XY_port variants as unnecessary > duplication with "X_port ... Y" variants. I am not sure what duplication you are talking about here. From Squid admin point of view, the following two are the same as far as "duplication" is concerned: http_port ... port http ... >From documentation point of view, common options may be documented in one place and referenced (or quoted) in another place. Documentation duplication exists in many places and needs a different/general solution, not specific to *port options. >From the developer point of view, the only code duplication that cannot be resolved without renaming the two directives is in the trivial parsing/dumping code that is hardly worth the renaming headaches. > Removing the need for 's' in http(s)_port with existing "ssl" parameter. In other words, adding the need for "s" to the "port http" parameter or adding the need for "transport=ssl" to "port http". > When FTP transfer protocol is added is the time to determine if the fpt_ > prefix is actually necesary or the *existing* protocol= parameter can be > used alone. Your long-term goal (still unclear to me at this time) and the resulting consensus will determine the shape of the native FTP port directive, but the existing protocol= parameter is not usable for FTP AFAICT. > FWIW the only strong reason http_ and https_ are currently > used is to determine which of the split config option lists to add the > PortCfg to. And this proposed step removes that need. The currently split port lists can be merged without renaming any squid.conf directives. >> Replacing all current Squid directives with >> >> squid old_directive_name_here old_options_here ... >> >> is obviously a bad idea. Thus, at some unknown point(s), merged >> directives become worse than dedicated ones. I suspect the key here is >> the amount of overlapping port options and typical configuration >> combinations. Is there enough common things about all Squid listening >> ports to warrant their merger? > > shared needs by all ports, both existing and needed functionality: > - host/ip:port resolution > - select loops prioritization over other ports > - SSL/TLS/DSTS options > - startup/shutdown operation and timings > > shared by TCP ports: > - TcpAcceptor class > > shared by UDP ports: > - recv > - separate outgoing IP:port selection > > Note that the difference between TCP and UDP classes is the listen > logic, which is initiated after the config lines is fully received. Let's come back to this once your long-term goal is clear. Currently, the discussion lumps together existing options, potential future functionality (that may need to be configured very differently), the needs of HTTP-specific options, the needs of other *_port options, code improvements, configuration clarity, etc. All those things are important, but it is impossible to carefully evaluate the proposal in such a complex environment when the end goal is unknown. Cheers, Alex.
