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

This discussion is also frozen...

Alex and Kinki suggest the function style, and looks that is a good
choice and there are very good reasons for doing this.

Are we OK to implement it like this?

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

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 - 09:42:41 MDT