Re: WG: [Dspam-user] New WebUI

On Aug 10, 2010, at 9:56 AM, Stevan Bajić wrote:

> On Tue, 10 Aug 2010 18:07:24 +0200 (CEST), "Imposit.com - webmaster"
> <[email protected]> wrote:
>> Sorry first mail wrong email account - dam zimbra - sorry again
>>
>> I agree her ewith Paul
>> Its not about Make jsut a new WebUi its the way the UI has to deal  
>> with
>> Dspam
>>
>> What i really dont like is that the UI has to deal directly with the
>> binarys
>> on the System. This is not good for several Reasons.
>> And i still dont like the Idea that any Webfrontend Deal with such an
>> important task as Dspam.
>>
>> its one thing it accesses some imageprocessing animal which i can  
>> chail
> in
>> a
>> chroot. but primary i think webprocesses should be jailed as max
>> where they are.
>>
>> But there is still the thing with quarantines. as long as they are  
>> files
>> we
>> need access there (which often leads to permission problems for  
>> several
>> users - they can be fixed but still another error source. Also they  
>> have
>> to
>> be where the webui is.
>>
>> so the dream of one webinterface for dspam on a seperate server (uhm
> that
>> would be soo fine :-) is not possible at the moment.
>>
>> we could easy write the summarys (like history) to an database yes.  
>> also
>> the
>> subject but mails to database is a bit harder.
>>
> You are so incredibly focused on that "everything in a database"  
> that you
> miss to see other ways.
>
>
>> Since we dont know their size yet we have to make junks and split  
>> them
> on
>> several records (otherwise you would have to make a very big max size
> for
>> mysql which is a nogo)
>>
> MySQL is not the only storage backend. That stupid MySQL is so  
> fucked up
> that you can not write blobs that are bigger then max size is a  
> problem
> that only MySQL has. You can not even do simple things like:
> 1) record 1 with a text field having the size of 2MB
> 2) record 2 with a text field having the size of 3MB
>
> Now try to do a simple SQL query like (assuming your  
> max_allowed_packet is
> 2MB):
> update mytable set data = concat(data,data,data,data) where id=1;
>
> It will fail. Yes. Simply. A simple 65byte query will fail because
> max_allowed_packet is not that what you sent to the MySQL server but
> includes the processed buffer of the SQL command. How gay is that? And
> MySQL is the only RDBMS that I know having such quirks. And this  
> kind of
> stuff is not something new. It is there since ages. Just look at  
> this here
> -> http://bugs.mysql.com/bug.php?id=22853 <- Yes. The year is 2006.
>
>
>> So without work done on dspam side we cant do a new webui - i mean we
>> could
>> but this would be just the old way and it make no sense just for
> replacing
>> perl
>> i personally dont care if its perl, php, python or whatever - what i
> care
>> is
>> that it should be seperated from the system
>> so no direct access to files, no direct change user when executing.
>>
>> So i was thinking about a solution without having quarantines in the
>> database. It would be easy.
>> Everytime something has to be done the webui could write into a todo
> table
>> and a cronjob on the system looks there every 30 sec or so and do the
>> requests.
>>
> Uha. This Mainframe (aka 1960) technology. Doing batch processing.
>
>
>> BUT one thing wont work. you could not view a quarantined message
>>
>> So my questions is - if we dont wanna have the quarantines in the
> database
>> how else can we seperate the webui form the system
>>
> 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 [email protected]
> - fetch statistics for uid 4
> - delete user [email protected]
> - delete uid 7
> - change preference XYZ to value ABC for user [email protected]
> - 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.

Regards,
Bradley Giesbrecht


------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspam-devel