On 05/25/2013 09:30 PM, Amos Jeffries wrote:
> On 24/05/2013 7:38 a.m., Tsantilas Christos wrote:
>> This patch :
>>
>> - adds support for quoted values in the entire squid.conf
>>
>> - warn about or prohibit values that can no longer be interpreted as
>> either quoted strings or simple tokens
>>
>> - support file:"path/to/file.name" syntax to load external configuration
>> files
>>
>> - support macros in "double quoted" values
>>
>> - support 'single quoted' values that do not expand macros
> Firstly, Design simplicity:
>
> I do not believe we need to present such a wide range of potential
> quoting and escaping mechanisms for squid.conf. We need to pick one
> style which will be familiar to our administrators and ignore the other
> styles. Double-quoting with \-escaping of " characters for strings is
> very well known and the type of encoding most often requested.
I do not want to step on Christos' toes, but since I asked him to add
support for 'single quoted' strings, I feel obligated to respond to this
part of the review.
While I agree that reducing the number of mechanisms is an important
optimization vector, the remaining mechanisms should be expressive
enough to form a convenient configuration language. IMO, preventing all
macro expansion in strings using single quotes is useful and common
enough (e.g., shell and Perl) to be supported along with double quoted
strings. I recommend but do not insist on its inclusion (until we have
enough user demand to back me up).
Other opinions?
> IMO, we should drop the '-quoted string handling from this. It is the
> first step on a slipery-slope toward arbitrary quoting styles and "why
> not also add {-quoted strings or [-quoted strings?". Those are becoming
> equally popular as people become familiar with YAML/SAS/JSON syntax.
Single quoted strings were added not because they were popular but
because they offer a unique functionality -- string-global suppression
of macro expansion. If {-quoted string or [-quoted strings offer
something equality useful they should be _considered_.
> Also by naming the class MacroUser you are adding a fourth term (macro)
> to describe these %things, we already have %-tokens, %-tags, %-format,
> and %-codes in use today. I think we should start to redux those terms
> usage rather than expanding with another variation on the theme.
Since "macro" is a familiar term describing _all_ of the things you
listed, it seems appropriate. Using "macro" does not _add_ one more
%thing. It offers a common, well-known term to refer to all %things
(which is much better than calling them "%thing", for example :-).
Cheers,
Alex.
