Kenneth Marshall wrote:
> I also agree that we should minimize big-brother coding unless it will
> actually be a fatal problem. For example, sbph being restricted to the
> hash driver would make it more difficult to work on making sbph work
> with standard SQL drivers.
>
I don't see a problem with it throwing out warnings, though:
WARNING: sbph is currently only recommended with the hash driver,
see limitations.txt
There is a balance between the work required to implement the checks,
and the time required to support people here and elsewhere when they
fall into common traps. If enough people make the mistake it becomes
worth putting the checks into the code (or maybe having a separate
dspamconf tool), in much the same way that documenting FAQs becomes
worthwhile.
Personally I try to see the human operator of the software as part of
the whole "package", and error-checking what they do is every bit as
important as error-checking elsewhere in the code.
--
Mark Rogers // More Solutions Ltd (Peterborough Office) // 0845 45 89 555
Registered in England (0456 0902) at 13 Clarke Rd, Milton Keynes, MK1 1LG
------------------------------------------------------------------------------
_______________________________________________
Dspam-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspam-user
