On Tue, Jul 09, 2002 at 10:00:49AM +0100, Iain Price wrote:
> Thats a bit unfair isn't it? I like the process responsibilities handed
> out in exim, listener, q runner, deliver, receiver etc etc. I'm not
> proposing that anything starts to have any control over anything else,
> more like just bundling a very dumb thing onto the daemon that listens
> for messages from children and just stores them, never replies at all,
> and then just spits them out when asked.
> (you could also ask the exim daemon to just print them to you as they
> arrive - on tap 'state debugging' of a running live system?)
>
> i know having any IPC that isn't text files on disks isn't the way exim
> works atm, but that doesn't mean it's 'evil'. disk file communications
> stop being useful at a certain point, and this is it, and info via
> signals is not much safer, and isn't very powerful (you can't be sure
> you didn't miss everything useful between polls :D).
>
> Of course, exim isn't my baby :) Maybe someone could write a 'contrib
> style' patch to implement this functionality for those who need it and
> dont care about the purity of the IPC :) Give them the choice eh?
Erm, the point isn't that it's a "'contrib style' patch", but a fundamental
change in the design of Exim. Maybe if you had some idea of the way the
code and the design works (hint, go read the specification) before shooting
your (virtual) mouth off, then people wouldn't think so badly of you. As it
is, you appear to have a fundamental misunderstanding of the software
development process.
MBM
--
Matthew Byng-Maddick <mbm@???> http://colondot.net/
