Kenneth Marshall wrote: > 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. > >
Indeed. IMHO, the best way to avoid possible conflicting configurations is through documentation, and that only. R's, Hugo Monteiro. -- ci.fct.unl.pt:~# cat .signature Hugo Monteiro Email : [email protected] Telefone : +351 212948300 Ext.15307 Web : http://hmonteiro.net Centro de Informática Faculdade de Ciências e Tecnologia da Universidade Nova de Lisboa Quinta da Torre 2829-516 Caparica Portugal Telefone: +351 212948596 Fax: +351 212948548 www.ci.fct.unl.pt [email protected] ci.fct.unl.pt:~# _ ------------------------------------------------------------------------------ _______________________________________________ Dspam-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspam-user
