Re: [RFC] unified port directive

After reading the thread a bit more I understood what the change was
about and I seem to understand what Alex is writing about.
we have
snmp_port
icp_port
http_port
https_port
htcp_port
announce_port (this first time I noticed it)
mcast_miss_port

And it's pretty self explanatory and descriptive in a way that I can
understand in a second.
Also I remember about some new feature of java which allows addition "_"
for number to make it more readable.
There is a point in making all the settings to be readable and if indeed
it will be simpler to use "port X options" i am for it.
But it seems to me that "htcp_port X" will become "port directiveY=X
PORT_NUMBER" which complex for me the current structure of squid
settings scheme.

Also I have just stumbled into nginx settings for some setup and the
only way for me to setup something was to copy and paste some long line
from the references example and then modify my custom args.
The reason for that was that it just didn't make any sense to me(at the
time and now).

In nginx they have the listen like this:
(indented) "listen IP:port option_one option_two=on XYZ;"
for one directive it's fine also for a whole scheme but if there is a
scheme to change it is a bit drastic.
Are there any good reasons for a change like this?
(I must say that even writing about it makes me think about myself as
the current settings state fan)

Eliezer

On 06/11/2014 11:09 PM, Alex Rousskov wrote:
> 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.
>
> 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?
>
> 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?
>
>
> Thank you,
>
> Alex.
Received on Fri Jun 13 2014 - 00:06:59 MDT