On Wed, 2003-09-17 at 16:03, Ettore Perazzoli wrote:
and a general outline of the implementation. On the other hand, all we got from you is random bitching on how much the idea sucks and random claims that "it has to be pluggable". What does "pluggable" mean in your world? My proposal is "pluggable" too; if we put the command-lines for "check for spam" and "learn that this is (not) spam" in GConf then it can be trivially made to work with any system. On the other hand, I don't know what *you* mean with "pluggable" because you haven't explained it at all.
Now that's what I'm talking about! I suppose the only difference from the "pipe to shell" option and the above is (as you have mentioned) the UI and the return value. I'm assuming that you will expect the program named in Gconf to return a 0 on success and anything else on failure (where success is defined as HAM and failure is SPAM) or at least be able to Evo what the message received is. The pipe to shell cannot handle return values, correct? If it could that would be awesome. Should Evo fork a child process to run the 'spam check' commands so as not to block the application. Has anyone thought how much extra time per message it will take to spam check incoming messages? Obviously you wouldn't want to fork a new child for *every* incoming message as the overhead of creating children would be large. I like the direction though. -- Christopher Ness Software Engineering IV, McMaster University PGP Public Key: http://nesser.homelinux.org/pgp-key/ 18:08:58 up 33 min, 1 user, load average: 0.20, 0.14, 0.09
Attachment:
signature.asc
Description: This is a digitally signed message part