Michael T. Babcock <[EMAIL PROTECTED]> writes on 17 August 2000 at 14:52:40 -0400
>
> ----- Original Message -----
> From: "David Dyer-Bennet" <[EMAIL PROTECTED]>
>
>
> > [EMAIL PROTECTED] <[EMAIL PROTECTED]> writes on 17 August 2000 at
> 11:32:00 -0700
> >
> > > I can't see much harm in being able to define the queuelifetime on
> > > an individual submission - perhaps limited to between 0 and some
> > > multiple of control/queuelifetime.
> >
> > The harm is in the increased complexity of the queue itself, and in
> > the programs that manage and access it. Increased complexity costs in
> > reliability, security, and resources consumed.
> >
> > I do agree that that feature has some benefit. I'm doubtful it's
> > worth the cost, but I have little idea what the cost would *actually*
> > be. Remember that there'd have to be some way to get the information
> > passed to the queueing engine, too.
>
> Oh come now. It may cost in speed. But it adds functionality. Any
> functionality like this can be coded in a secure and reliable manner, so
> those shouldn't be cited as reasons to avoid the issue.
I'm not an expert on software complexity and error probabilities. But
what you've just said is someting I understand to be a very common
misconception. Features add complexity. Complexity adds chances for
things to go wrong in unexpected ways. Even apparently simple,
isolated, features. But to get deeper analysis and more detail, you'd
need to find somebody more knowledgable than me; I know the results
more than the evidence.
--
Photos: http://dd-b.lighthunters.net/ Minicon: http://www.mnstf.org/minicon
Bookworms: http://ouroboros.demesne.com/ SF: http://www.dd-b.net/dd-b
David Dyer-Bennet / Welcome to the future! / [EMAIL PROTECTED]
