John White wrote:
> On Fri, Jul 21, 2000 at 11:20:00AM -0400, Michael T. Babcock wrote:
> > No, but if qmail is making the deliveries to another MTA, that MTA doesn't
> > have much choice about whether its going to accept deliveries from Qmail or
> > not, so why not make Qmail a nice neighbour while we're at it?
>
> > There's nothing wrong with using intelligent queuing to reorder messages and
> > reduce session #'s.
>
> Sure there is. It creates overhead.
So does opening simultaneous connections -- in the kernel, just not in
user-space. Silly argument. SCSI command queues with reordering and elevator
sorting add a lot of overhead ... and happen to increase performance
dramatically. There are trade-offs in writing software. I'm not saying my way is
perfect. I'm saying I think I have valid concerns (that others on this list have
also stated) and they shouldn't be written off with 'it creates overhead'.
> > If just getting the mail out FAST is all that matters,
> > fine. But that's NOT all that matters.
>
> To be blunt, I don't mind taking a look at the code changes you're
> proposing. Where are they?
(Sarcasm:) What, you don't know how to code?
I'm sick of that response. If I'm a part of three different OSS projects and work
60 hours a week for a living on top of that, am I expected to give you a
demonstration of my thoughts in code just so you can say they suck? If I had the
time to write my modifications, I wouldn't propose them. I'd have written them,
posted the patch and let everyone who agrees with me just use it (like other
patches at qmail.org that aren't in the distro).
I don't have that time, so I gave my observations and opinions instead for the
sake of intelligent discussion. Ideas are equally valuable to working solutions.
The latter usually doesn't appear without the former.
