thought [was: bulkmode registration patch]

[David Relson]

At 08:43 PM 5/6/03, Matthias Andree wrote:

>David Relson <relson at osagesoftware.com> writes:
>
> > With the attached patch, bogofilter passes "make check" as well as a
> > cursory test (27 messages, registered via "bogofilter -s -b -v < list -d
> > dir").  The code is believed to work, though it hasn't been stress tested.
>
>As a medium-to-long term thought:
>
>I wonder if we should really consider splitting bogofilter into a
>backend that has low-level functions (will be akin to a library) and a
>frontend that does message-splitting, option parsing and all that. The
>backend would be shared by bogoutil and bogofilter as some parts of it
>are now, and we could separate out the front-ends.
>
>Front-ends would be separated by their purpose. I don't necessarily plan
>to map every mode into a distinct file, but combining a "fetcher" module
>from a set of several (maildir, mbox, single_mail) with a "parser" and a
>"driver" module (that evaluates or registers) or something might work.
>
>This is raw, not well thought-out and we need to find what a useful
>separation would be. After that, we'd need to define the
>interfaces. I've wondered if we should make at least the "evaluate if
>spam or no" mode easily accessible from other applications.
>
>This is nothing for short notice, if we don't plan where we cut and the
>interfaces, we can just drop this idea.

At present a bunch of .c files are compiled and libbogofilter.a is 
built.  The individual programs, i.e. bogofilter, bogolexer, and bogoutil, 
each has its own .c file and they are built by compiling the .c file and 
linking in object modules from libbogofilter.a.

Another program can be built in this same manner - .c + libbogofilter.a --> 
program.  So, any of bogofilter's functions can be included as part of 
another program by linking in the library.  Since this is doable, I'm 
guessing that its not what you had in mind.

My other thought is a bogofilter daemon, to be used via a client-server 
interaction.  The daemon (server) would always be running and 
classification (or registration) would consist of starting the front-end 
(client), passing the message (or tokens or something) to the server, and 
receiving the result.  Is this what you mean?

David