On Mon, 06 Sep 2010 23:13:23 +0100, Andrew Beverley <[email protected]> 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
