Re: [RFC] unified port directive

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.
Received on Fri Jun 13 2014 - 14:45:50 MDT