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.
