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. > > 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 I am tryingto get rid of the XY_port variants as unnecessary duplication with "X_port ... Y" variants. Removing the need for 's' in http(s)_port with existing "ssl" parameter. 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. 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. > > 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. Amos
