Re: Patch to add netfilter mark support

On Mon, 06 Sep 2010 23:13:23 +0100, Andrew Beverley <andy_at_andybev.com>
wrote:
> On Mon, 2010-09-06 at 23:06 +0100, Andrew Beverley wrote:
>> > >
>> > >> * I find the terminology inconsistent and confusing: outgoing,
>> > >> clientside, upstream. No wonder you have to explain the difference
>> > >> twice. Unless these are all standard RFC-like terms, please use
>> > >> something consistent like fromClient, toClient, fromServer,
>> > >> toServer.
>> > >> Others may suggest a better scheme, but this one at least does not
>> > >> require constant doc lookups to understand where "out" and "up"
is.
>> > >
>> > > Agreed. This confusion is also present in the names of the
>> > > configuration
>> > > parameters: initially I found the current ones confusing (it took
me
>> > > a
>> > > while to realise that one was server side and one client side).
>> > >
>> > > At the minute they are tcp_outgoing_tos and clientside_tos. Would
>> > > there
>> > > be any objection to changing the tcp_outgoing_tos to
serverside_tos?
>> > > Or
>> > > would you prefer not to break existing squid.conf configurations?
>> >
>> > IMHO, both: Change the documented/primary option names but accept the

>> > old ones with a "deprecated" warning. There may even be a built-in
>> > mechanism for that (multiple NAME values?), but I am not sure.
>>
>> Ah yes, you can specify multiple NAME values. Funnily enough, this is
>> already the case for tcp_outgoing_tos, which is also known as
>> tcp_outgoing_ds and tcp_outgoing_dscp. The disadvantage of this is that
>> it doesn't display a deprecated warning.
>>
>> > You probably want to wait for others to comment before changing
>> > squid.conf option names though.
>>
>> How about I change the "default" name to serverside_tos, and leave
>> tcp_outgoing_tos with tcp_outgoing_ds and tcp_outgoing_dscp as an
>> accepted name?
>
> Or maybe they should be serverside_outgoing_tos and
> clientside_outgoing_tos to make it even clearer?

The "side" terminology is fairly internal to us developers. Just
client_outgoing_tos etc would be clearer to most users.

And as Alex indicated there is a mechanism already in place for handling
simple name changes. Add multiple entries on the src/cf.data.pre "NAME:"
line with the current preferred name first. Parser needs the usual updates
to handle the new name text identical to the old one and emit a deprecation
WARNING: about the option upgrade on the old ones, and to dump using only
the new name.

I'm okay with these updates. More nervous about the qos_flows changes. As
the 3.2 series grows older it gets more difficult to upgrade config under
people.

Amos
Received on Mon Sep 06 2010 - 22:40:04 MDT