Geo Carncross wrote: > >>But I guess Geo want's to be able to both fork and stay attached, >>something currently not accomodated. Would be rather trivial though. > > > No I don't. That's not what I want at all. I simply want to move dbmail > into category #1 instead of category #2 so that people will _stop_ > making programs that run in #3 or #4.
>From my point of view this is the age-old policy versus mechanism debate. As maintainer I don't much care other than not wanting to present the current userbase with unexpected behaviour by changing the default. I do care about helping my users (like yourself) with providing the mechanisms to implement whatever policy they prefer. > I really need to work on my communication skills, don't I? :) Is that your S.O. talking ?... So I suggest we implement 3 runmodes: 1. DAEMON: use-case: init.d scripts double fork, detach, prefork workers 2. SERVER: use-case: inittab stay attached, prefork workers 3. SINGLE: use-case: (x)inetd, ssh-tunnel stay attached, single process worker only. Since we already support 1 and 3, adding 2 would make this picture complete. We could then also allow selection of the default through configure (compile-time) or dbmail.conf (runtime), or both. Would that make you happy? -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl
