Stevan Bajić wrote:
I think Steven hit the nail on the head. Actually, I was also of the opinion to put everything into the database. But seeing how Steven expounded on the whys and wherefores, I agree that the flexibility of being able to process both file-based and SQL-stuff will be better for DSPAM in the long run.On Mon, 05 Jul 2010 15:52:49 +0200 Tom Hendrikx <t...@whyscream.net> wrote:On 05/07/10 09:51, Stevan Bajić wrote: After all the Web-UI has been the part most DSPAM users have said to work on if the project would become open source.True.The last time I checked into discussions on this issue, the main point was IIRC that building a new web interface around the command line utilities (as the current one is), is not a nice and viable solution. The proposed solution was to update DSPAM so that it uses a database for all actions, so the web interface can hook directly into the database, without messing with commandline/suexec etc, or reading css or group files directly from disk.IMHO it will be hard to implement something that can do all the functions only by accessing data from the database. The retraining and training part will need DSPAM functionality. Reading the data from a database will not solve that need.I am not sure whether the work that should be put into this, was ever considered by Stevan (or any other potential developer/contributor)? If not, maybe some thinking on this could be done. I'm all for a new web gui (including contribution), but I do not feel the need to create a new gui that does all the problematic stuff wrong all over again.A good developer would code an abstraction layer that would be capable to handle everything right, regardless where the data is resisting. Be it on disk or in a database. My personal feeling is that people got so much obsessed with this "everything in a database" that they missuse this as an excuse to not start coding/building a new web ui. I know, I know. A lot of users are dreaming and claiming that everyting being in a database will automagicaly solve all issues. But it is not going to be that case. And those claiming that everything should be in a database... let me ask you guys what IMAP server are you using. Everyone using Cyrus, Courier, Dovecot, I don't know what else... should explain me why they are not using DBMail to store everything in a relational database? And what about logging? Are you logging everything to a database? What about user credentials? Are they in a SQL database? What about WWW data? Is ALL your web data in a database? What about..... I think you guys get the point. And now back to DSPAM. What is the strength behind DSPAM? What are our unique selling points? I think one of them is sure that we offer many tokenizers (word, chain, osb, sbph) and offer many algorithm (burton, robinson, etc...) and offer many backends (SQL based (MySQL, PostgreSQL, SQLite) and file based (CSS)), etc... What is now the problem with this? Why this obsession in having everything in a database? Why can we not construct a web ui that is capable to handle SQL based stuff and file based stuff? Are we as developers so incapable to make something that is capable to handle both worlds? We already today have a big discrepancy between different storage backends. For example the preference extension is only available on MySQL and PostgreSQL. Then group support is as well only available on MySQL and PostgreSQL. The by fastest storage backend is (guess what) file based. Yes. It is CSS. It is fast as hell and leaves all the other storage backends by factors behind. And the by far simplest solution (in regards to dependencies) is again a file based solution (yes, yes. It is CSS again). And and and... And guess what? Each of those storage backends has a reason to be there. Each of them has their benefits. And why being narrow in the future and kill some of them just because we as developers are lazy to turn on our brain gears and produce something that can handle all backends? 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?-- Regards, Tom
-- Peter Santiago pet...@psinergybbs.com My website: www.psinergybbs.com My spamtrap address: r349...@psinergybbs.com
smime.p7s
Description: S/MIME Cryptographic 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
