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.
