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. >> >>