On Tue, 10 Aug 2010 10:52:30 -0700 Bradley Giesbrecht <bradley.giesbre...@gmail.com> wrote:
> > On Aug 10, 2010, at 9:56 AM, Stevan Bajić wrote: > [...] > > Pretty simple: Extend the DSPAM server protocol to allow you to do > > all the > > tasks needed. Stuff like: > > - fetch message X from quarantine for user Z > > - delete message Y from quarantine for user Q > > - train signature 2,abcdef12345678 > > - train signature 987654321abcdef for uid 3 > > - fetch statistics for all users > > - fetch statistics for user max.mus...@domain.tld > > - fetch statistics for uid 4 > > - delete user max.mus...@domain.tld > > - delete uid 7 > > - change preference XYZ to value ABC for user max.mus...@domain.tld > > - etc.... > > > > And just forget where the quarantine is saved, where the log is saved, > > where data is saved, preferences, etc... don't think about it. Let the > > DSPAM server handle this. Wherever the data is. It's not your > > problem. Flat > > file, CSS file, MySQL database, SQLite DB, etc... it is not important. > > Perfect. > IMHO that would be a way simpler solution then building a Web-UI that has logic to access MySQL, PostgreSQL, SQLite2, SQLite3 and Hash. And on top of that the Web-UI would still need some more logic to handle all the tasks needed. While all that needed logic is +/- already available and build into DSPAM it self. So instead of extending the Web-UI to do more, why not make it more simpler? Why not laverage what we already have (the client/server part) and use that? Why not just use (DSPAM) LMTP protocol and build on top of it? We already use LMTP when talking from the client to the server and we already have encapsulated into LMTP the possibility to classify, process and re-learn. This all aready is there and is used since ages. So extending this and allowing to do more is IMHO the logical consequence. This would allow us to keep +/- everything we currently have while allowing us to decouple the Web-UI from the system where DSPAM is running. I am not telling that this is the ideal and super best solution. No. All I say is that it is easier and it will gain us some time to rething the whole architecture while still allowing us to move slightly ahead and decouple the Web-UI from the binaries DSPAM uses. And all this by just extending one function inside DSPAM. Only the code that is handling the input over LMTP would need to be extended to allow additional commands. Probably we would still need to move some logic from the helper tools to be either inside libdspam or another library but that should be no big deal. Just move current code to a library and make the helper tools call those functions instead implementing them on their own. > Regards, > Bradley Giesbrecht > -- Kind Regards from Switzerland, Stevan Bajić ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Dspam-devel mailing list Dspam-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspam-devel
