[Spambayes] proposed changes to hammie & co.

[Richie Hindle]

[Tim Stone]
> I'm not sure I understand why you're using asynchat and asyncore.  

[Skip]
> Makes it (relatively) easy to talk to multiple connections simultaneously
> without resorting to multiple threads.  It requires you to reorient how you
> look at such things, but once you understand the model it's pretty easy to
> program.

To expand a bit on this a bit, it means that you can have the existing HTML
user interface, your configurator, and multiple POP3 proxies, all
potentially being used by multiple simultaneous users, all within one
thread of one process and all sharing common data structures (the 'options'
object, a Classifier instance, etc) without ever having to worry about
synchronising anything.

At the moment, for instance, we have a potential (and rather contrived I
admit) problem whereby your configurator could be halfway through writing
the ini file when the POP3 proxy tries to read it.  Using asyncore to run
everything within one thread of one process prevents that entire class of
problem with no extra effort.

Asyncore works in exactly the same way as your methlets - it takes away the
procedural programming job of reading and writing sockets, and instead asks
that the programmer writes event handler functions.  Your

    OptionsConfigurator.homepage(self, parms)

is an event handler for the "someone is asking for the homepage" event.
This is exactly how my async-based HTTP server works - my

    UserInterface.onHome(self, params)

does the same job for the pop3proxy.py HTML user interface.  The plugin API
I have in mind will work exactly that way - and there'll certainly be no
requirement for the plugin programmer to know about asyncore.

-- 
Richie Hindle
richie@entrian.com