On 06/07/10 23:49, Paul Cockings wrote: > >> If we are going to remove the file based backends... then what next? Are we >> going to remove all the tokenizers and then just leave one? And then? Are we >> going to remove all the algorithms and just leave one? >> >> I really think that DSPAM is a unique Anti-Spam solution and one part of >> this uniqueness is that it is very flexible. So why are we not cultivating >> and extending this flexibility? Why are we so lazy and are trying to kill >> this diversity? > > We need more quality developers >
Accessing file based backends without having a unified interface for
them in an external language (forcing the developer to use system calls)
is a pain in the ass. Database access is supported in all major
programming/scripting languages.
Anyway, I never argued for removing file based backends. I merely
suggested at dropping initial support for them in the web gui (i.e. not
in DSPAM itself). Of course, the backend code could (and should) be
written in such a (modular) way that a driver for file-based backends
could be added later without much hassle.
--
Regards,
Tom
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________ Dspam-user mailing list Dspam-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspam-user
