On 01/09/2016 12:35 PM, Eliezer Croitoru wrote: > On 08/01/2016 17:27, Alex Rousskov wrote: >> On 01/07/2016 07:03 PM, Eliezer Croitoru wrote: >>> I added a configurable option to the ICAP services named "nodown" but >>> maybe another name would be better fit.
>> Please do not use negative option names. If this feature is committed >> despite my objections, please consider using "always-up" or another >> positive name. > Both nodown and always-up do not describe the exact meaning of the flag. > Do you(..and others) think that a longer name would be better? something > like "options-only-suspened" or "suspend-only-by-options-fail" ? Let's finalize the scope of the changes before deciding how to name them. My comment above was specific to the "negativity" of the name you have chosen. The negativity should be avoided regardless of the feature scope. As for the scope of the changes, I continue to think that a different solution is needed. > I was thinking about it but this feature eliminates every suspension > between each OPTIONS fetch\check. IMO, the need for "eliminating suspension between OPTIONS" should be addressed by adding an adaptation_failure directive driven by ACLs instead of adding optional hard-coded decision logic. For example, # "allowed" adaptation failures are not counted as service failures adaptation_failure allow all > I know it doesn't fit all setups but ... Being applicable to "all setups" is impossible and is not required for an optional feature to be accepted. However, while your specific use case is important, we ought to consider other use cases as well, especially when adding new configuration options. The adaptation_failure directive will address a lot more use cases, including yours. It is not difficult to implement. Thus, if we add something, we should add the more general adaptation_failure (or similar) support and not nodown (or similar) support. > the idea is that the service is essential and the proxy cannot allow any > traffic without this service Also known as the default bypass=0 setting combined with the "send all requests to this service" adaptation_access rule. This is already fully supported. What Squid does not yet support is an admin-configurable classification of adaptation failures: Which adaptation failures are specific to the adaptation transaction and which are a sign of a failing adaptation service? Your "nodown" proposal classifies all adaptation failures as non-service failures. We can do much better without a lot more work. > Do you think a wiki article will be good enough to explain the use cases > of this option instead of the documentation? I think we need a different configuration option or two. I do not think the right new options require extensive documentation on the wiki, but describing your specific use case and how you have handled it using those new options may be useful for many admins, of course. HTH, Alex. _______________________________________________ squid-dev mailing list [email protected] http://lists.squid-cache.org/listinfo/squid-dev
