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