On 01/28/2014 11:11 PM, Kinkie wrote:
> IMO it is right for paths to be absolutely configureable in squid.conf.
> At the same time, I see nothing wrong with having a concept of an
> "instance name" which could default to "squid" or to "" when not
> provided.
The above matches the approach I am rooting for. The only difference is
that I try to be careful to talk about "paths or path prefixes", not
just "paths", because I do not want others to say this:
> A default Squid will need the following new directives:
>
> collapsed_forwarding_metadata_shm
> collapsed_forwarding_queues_shm
> collapsed_forwarding_readers_shm
Which is indeed "too much" for the currently known use cases.
Configuring a single path prefix for all shared memory segments is
probably sufficient for now:
shared_memory_path_prefix ...
(or some other, better directive name)
> So, IMO:
> - every possible path should be explicitly configureable in squid.conf
> or command line. When a path is fully specified, it overrides everything else.
> - I see nothing wrong with taking an optional parameter to influence
> the default values of unspecified paths to something less hardcoded
> than now. The general structure we use is consistent with GNU
> guidelines, and I would recommend not to change that. At the same
> time, having a "-${servicename}" added to file name defaults when
> servicename is specified by the admin won't hurt.
Yes, with the "path or path prefix" caveat.
Cheers,
Alex.
Received on Wed Jan 29 2014 - 17:07:47 MST
This archive was generated by hypermail 2.2.0 : Wed Jan 29 2014 - 12:00:14 MST