On Thu, Jul 02, 2009 at 02:32:03PM +0200, Steve wrote: > Hallo Tom, > > > > Steve schreef: > > > I see a bunch of issues: > > > > > > 1) You should NOT use SBPH with MySQL driver. The only driver able to > > handle SBPH without issues is the hash driver. Please use something else > > then > > SBPH. I would suggest OSB. > > > > > > > There seem to be multiple issues with some of these configuration > > options, notably combintaaions between Algorithm, Tokenizer and the > > various storage drivers. Maybe dspam could check for these and exit with > > a "configuration error" when incompatible choices are made? > > > They are not incompatible by definition. It is more a technical limitation > then a real hard incompatibility. I understand that a "configuration error" > would be nice and dandy but where to start and where to stop? I mean what > conditions do trap a "configuration error" and which one are not going to > trap a "configuration error"? The possibilities for making errors in the > configuration are endless and a procedure to check them all would be huge. > Hard configuration errors are anyway trapped and DSPAM will refuse to > run/work/process/whatever if you set some options. But the above mentioned > condition is more or less a technical limitation and as time passes it could > be easily happen that a new release of the RDBMS could cope with the load of > SBPH. > I personally would not extend the current code to check each and every > (stupid) combination of options. Some things are better left to be done > outside by humans then internally by code. But that's my personal opinion. I > don't own DSPAM. It's a tool for us all. If the majority of the user base > would like to have that extended error checking then we could look to > implement it in the next release after 3.9.0. Depending on how the checking > is done it could be however that the checking is going to eat some processing > time when using DSPAM. For me that would be a big no-go. I am all for > trapping hard configuration errors but leaving the soft configuration errors > to be resolved by the user/admin using DSPAM.
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. Cheers, Ken ------------------------------------------------------------------------------ _______________________________________________ Dspam-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspam-user
