On 12/04/2015 11:04 PM, Amos Jeffries wrote:
> On 5/12/2015 8:42 a.m., Alex Rousskov wrote:
>> I am not against adding +n support, but I do not recommend forcing users
>> to add +n, just like we do not force them to add +i.
> Then do you thik -n is used rarely enough to warrant breaking BC silently?
Personally, I do not, but this is not my area of expertise so others'
voices (including yours) should carry more weight. My paragraph above
was about new configurations, not about BC. That was misleading; sorry.
> Because having warnings about the line change with no way to silence
> them in the case that it was intentional is not a good option.
I agree. On the other hand, forcing explicit +n in new configurations is
not a good option either.
I see two reasonable solutions:
A. Rename -n to -d (--direct), -a (--as-is), or similar (the exact new
name is not important to me). Warn about inconsistent old -n use. Do not
warn about "inconsistent" -d use. If the upgrading admin was
[incorrectly] interpreting -n the way we implemented -d, then all they
need to do to quiet the warning is to replace every -n with -d, which is
fairly easy.
B. Add a general BC and/or warning suppression mechanism:
101:acl foo dstdomain v1
102:acl foo dstdomain -n v2
squid.conf:102: Warning: Inconsistent -n use within acl foo
squid.conf:101: previous acl foo line without -n
... and many more such warnings,
... one for each acl that uses -n inconsistently (at least)
Now the admin adds a warning suppression directive:
100:backward_compatibility acl-n-applies-to-one-line
101:acl foo dstdomain v1
102:acl foo dstdomain -n v2
squid.conf:100: Warning: Not warning about acl-n-applies-to-one-line
... and no warnings about inconsistent -n use follow ...
In the extreme, we can even silence that single warning above:
backward_compatibility \
acl-n-applies-to-entire-acl \
no-backward-compatibility-warnings
I like (B) because it is a general mechanism we can reuse for many
future upgrades as well.
Any better ideas? Which BC handling method do you prefer?
>> (-i
>> support preserved for backward compatibility, but I would probably warn
>> about it anyway). Such support does not really add much value AFAICT,
>> but the resulting ACL lines become more and more difficult for a human
>> to interpret correctly because each flag "area" overlaps subsequent
>> flags on the same line. KISS.
>
>
> Maybe we should deprecate +i and warn admins to split the line where the
> +i is?
> If you agree, that change and WARNING can go in immediately.
I would agree (to streamline acl syntax), but, again, I do not assign
much weight to my preferences regarding such BC issues.
Also, we may want to add something like (B) above before we add more
warnings that require non-trivial squid.conf changes. Please keep in
mind that many squid.conf files are generated by programs so changing
them requires going through a more complicated _process_ than running a
sed script on a static file.
>> General flags in front of lines loaded from an acl parameter file should
>> be supported.
> You mean in the data file or the squid.conf?
data file
> If you mean the data file, that sounds like its moving the goalpposts of
> this proposal. It can be planned to allow for future addition, but not
> in scope for coding yet.
I thought -i and even perhaps -n in data files is already supported. If
not, I completely agree that support for flags in data files should not
be added during this project -- it becomes a separate issue that we just
need to keep in mind.
> I assumed that since this proposal was coming from you it was a Factory
> intention to do anyway. Just design details and timing to organize.
Factory can do it, but if somebody else can do it quicker, they should
speak up!
> January sounds like it would be just scraping into the beta cycle. But I
> do request that back-compat warning happen within the next few weeks, so
> we can at least start to see if the assumptions are correct.
I cannot promise anything within the next few weeks, but perhaps
somebody else will volunteer to contribute [this part of] the changes.
Let's try to agree on how to handle BC issue first.
Thank you,
Alex.
_______________________________________________
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev
