Re: [MERGE] Clean up htcp cache_peer options collapsing them into a single option with arguments

On 08/23/2010 06:36 PM, Amos Jeffries wrote:
> On Mon, 23 Aug 2010 15:28:23 -0600, Alex Rousskov
> <rousskov_at_measurement-factory.com> wrote:
>> On 08/22/2010 07:17 AM, Amos Jeffries wrote:
>>> Henrik Nordstrom wrote:
>>>> the list of HTCP mode options had grown a bit too large. Collapse them
>>>> all into a single htcp= option taking a list of mode flags.
>>>>
>>>
>>> Updated version of Henriks patch. (why did it not get committed last
>>> year when approved?)
>>>
>>> * parser bug fixed to handle a list of exactly one parameter without
>>> trailing comma (which the original would call bungled).
>>>
>>> * special parse case for htcp-oldsquid fully combined with new parser.
>>>
>>> * alters the cachemgr config dump to show the new syntax.
>>>
>>> Other than parse no operational changes. Fully backward-compatible and
>>> tested.
>>
>> This is not an objection to the patch, but if the various htcp-foo
>> options set combine-able flags rather than a single "htcp" value, then
>> please consider using "htcp::flag" namespace syntax instead of the
>> "htcp=flag" assignment syntax.
>
> Some are combinable some are mutually exclusive. They all enable HTCP
> communication plus setting additional behaviour modifiers. The basic config
> is just an "htcp".
>
> The point of this change was to avoid a series of individual flag entries
> on the cache_peer line. The possibility of doing multiple behaviour
> 'assignments' is retained for backward-compatibility but is not exactly
> desirable and undocumented to discourage.
>
> ie the syntax meaning of "htcp=oldsquid,no-clr" is: HTCP on, with oldsquid
> behaviour but no CLR requests.

Sounds good. Since values are flags that we do not really assign, you
could still do htcp::oldsquid,no-clr, but it is not clear to me whether
that would be really better than assignment.

Thank you,

Alex.
Received on Tue Aug 24 2010 - 03:47:25 MDT