[Spambayes] A most peculair problem with SB 1

Robert Neuschul robert at imagine.co.uk
Thu Nov 11 02:19:33 CET 2004


Tony

> OK then, so what about I change pop3proxy_service.py to (when run with
> "install") look for an existing configuration file and if there isn't one
> create one in the parent directory of the script.  This would mean:
> 
>   * Binary: in the (eg) \Program Files\SpamBayes directory, so the cache
> directories would be at the same level as the 'bin', 'lib', and 'doc'
> directories.
> 
>   * Source (outside Python): in the root spambayes directory, so the cache
> directories would be at the same level as the 'contrib', 'spambayes',
> 'windows' (etc) directories.
> 
>   * Source (inside Python): in the root Python directory, so the cache
> directories would be at the same level as the 'Lib', 'DLLS', 'Scripts' (etc)
> directories.

Any of these /should/ work: we'll only know by testing :-)
If necessary I'll setup a dedicated sandpit box for this and we can find out 
how it handles - I'm nervous of playing too much more with the existing box 
since it's actually the domain primary :-)

> The directory that is chosen gets:
>   
>   * the bayescustomize.ini file
>   * the hammie.db database
>   * the spambayes.messageinfo.db database
>   * the pop3proxy-ham-cache, pop3proxy-spam-cache, pop3proxy-unknown-cache
> directories
> (IIRC, that's all at the moment).
> 
> Alternatively, I could get it to create a (eg) "SpamBayesData" directory in
> the parent directory of the script.  It would then be in the places
> described above, but have the three files and three directories inside it.
> That's tidier, although slightly more complicated.

Again; these sound like eminently sane proposals: my concern would be that 
whatever directory name is chosen and used makes it blatantly clear to 
inexperienced first-time installers from reading the directory name that 
"this" is where one looks for the config and databases etc. It took me, as a 
relatively experienced user of Windows systems, some time to figure out where 
everything was - the subdirectory names aren't always instantly intuitive.

> This is do-able as well.  I'll try and create something that does this later
> today.  (As an aside: it would be nice in many ways if all the spambayes
> code was converted to use the Python logging module rather than print
> statements (the Outlook plug-in actually has it's own logging system), and
> things like this would be much simpler and easier to change as necessary.
> That's a fair bit of work, though - maybe it'll make it to 1.1, but maybe it
> won't).

I can sympathise with all of that: Windows logging is a nightmare at the best 
of times - each of the commercial application developers seems to think 
they've found a new and better way: it can be quite stunning to run a global 
search on *.log and find out just how much unread stuff has accumulated on the 
system. At least with WMI one has the option to place logs into the core 
repository - which most experienced users /do/ know about - and my memory of 
the Python logging is that it can use Windows Instrumentation fairly 
effectively. 

ATB,

Robert.




More information about the Spambayes mailing list