Re: [PATCΗ] Quoted values in squid.conf

On 06/18/2013 03:42 AM, Tsantilas Christos wrote:

> What are you suggesting file("location") or parameters("location")?

parameters() or options() seems better to me because the code actually
loads a squid.conf directive parameters. It cannot load directives
themselves this way (we have an "import" keyword for that).

I think I prefer parameters() because the current squid.conf text uses
"option" instead of "directive" in many places. "Parameters" would not
add to that confusion.

HTH,

Alex.

> On 06/04/2013 05:55 PM, Alex Rousskov wrote:
>> On 06/03/2013 08:31 PM, Amos Jeffries wrote:
>>
>>> In summary we seem to be talking about different features here.
>>
>> I am afraid your summary is incorrect, which may explain why we cannot
>> reach an agreement:
>>
>>
>>> 1) the syntax for linking access method and location.
>>> * this seems to be agreed as ":" in URI-style.
>>
>> There is no disagreement here, but this is not what we are (or should
>> be) talking about.
>>
>>
>>> 2) whether and how add a new parameter,
>>
>> No, this is not particularly important. Additional arguments are only
>> mentioned as something we are likely to need in the future so the syntax
>> should accommodate their future addition nicely (but we are not going to
>> support them now).
>>
>>
>> The primary thing we should be talking about is how the parser will
>> identify the places where an inclusion of directive parameters has been
>> requested. The current proposals revolve around the following schemes
>> (item zero is what Squid currently supports -- it is not being prosed as
>> it clashes with the new quoted strings support, but is given here for
>> completeness sake):
>>
>> 0) directive_name ... "location" ...
>>
>> 1) directive_name ... file:"location" ...
>>
>> 2) directive_name ... parameters("location") ...
>>
>>
>> I suggest that we use function-like style in #2 because:
>>
>> a) It does not create two string: prefixes when location becomes a URI.
>> b) It uses a function call concept that many admins are familiar with.
>> c) It can naturally support resources that are not files.
>> d) It is easy to extend with more function names when needed.
>> e) It is easy to extend with more function parameters when needed.
>>
>> Please note that the exact function name in #2 is to be decided
>> separately (could be "parameters", "load", "include", or something else)
>> and the location parameter in #2 may start with a "file:" prefix. These
>> are all secondary issues.
>>
>> Item (d) is not unique to #2 because #1 can also be extended using
>> different prefixes. However, #1 prefixes are more likely to cause
>> clashes with old tokens if some of the extended usages do not require
>> quoting the parameter after ':'. The function style does not have this
>> problem.
>>
>>
>>> NP: the 1-per-line behaviour is quite nasty. But we seem to be stuck
>>> with it from the existing acl directives usage?
>>
>> Let's not discuss it here. This thread is long (and evidently confusing)
>> enough without adding more controversial topics.
>>
>>
>> HTH,
>>
>> Alex.
>>
>>
Received on Tue Jun 18 2013 - 16:20:36 MDT