Re: [RFC] Squid process model and service name impact

> "hard-coded" is being used a bit much here. I don't think any of us are
> arguing for that.
> Lets look at the BNF:
>
> FOO.pid = chroot pid_filename
>
> chroot = {squid.conf chroot} | "/"
>
> pid_filename = {squid.conf pid_filename} | DEFAULT_PID_FILE
>
> DEFAULT_PID_FILE = {./configure --with-pidfile} | ( PREFIX "/squid.pid" )
>
> PREFIX = {./configure --prefix} | "/"
>
> We have no less than 4 configuration points for this one file, some of which
> replace others , and some join unless other has been configured. I am
> proposing we can do with a simpler setup:
>
> FOO.pid = chroot DEFAULT_PID_PATH "/" service_name ".pid"
>
> chroot = {squid.conf chroot} | "/"
>
> service_name = {squid -n FOO} | "squid"
>
> DEFAULT_PID_PATH = {./configure --with-pidfile} | PREFIX
>
> PREFIX = {./configure --prefix} | "/"
>
> Most of the configuration is in path. The file name part is "static" but
> configurable via command line with less of the per-worker problems brought
> in by squid.conf flexibility (chroot still suffers those).

Sorry for coming in only now, but isn't this a bit limiting?
I mean, under this proposal there is no way of escaping DEFAULT_PID_PATH..
I suspect this discussion is starting to transcend the problem it aims to solve.
I'll get my 2c in:
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 trick is in trying to make it all self-consistent; then
legacy comes in to make things complicated.

So, IMO:
- every possible path should be explicitly configureable in squid.conf
or command line. We're almost there but not (see shm). When a path is
fully specified, it overrides everything else.
- if needed, we could make config-file parsing a multi-pass affair,
after all it's not really performance-critical, to have early pickup
of options which influence later decisions. I suspect the effort would
be significant, but let's ignore that for now
- 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 .

-- 
    /kinkie