Filter API

Russ Allbery rra at
Wed Jun 19 19:12:11 UTC 2002

Alex Kiernan <alexk at> writes:

> On the TODO list we have "The interface to embedded filters needs to be
> reworked". I've got to the point where I desperately need some light
> weight filtering (so I really want to write it in C), hence implementing
> something for this has become a priority fo me.

> Has any thought gone into the design for this? If not I can try & knock
> something together since I'd rather try & sort out the mess than adding
> to it!

As far as I'd gotten with the thinking was something like this:

There are a few basic operations that one runs through the filters.  In
INN, it's filter message and filter message ID.  In nnrpd, add filter a
post, new connection, new authentication, attempt to read a group, and
attempt to post to a group (roughly).

For at least the filter message and filter message ID sorts of things,
what we want is a stack of filters registered by the various filtering
back-ends (Perl, Tcl, Python, whatever) so that INN can just tell the
filter code "here's an article" and the filter code walks through the
registered handlers in order or returns quickly if filtering isn't turned

For C filters, you kind of ideally want dynamic loading of shared objects,
but that was more than I was going to tackle in the first round.  But
regardless, it should be hidden inside the filtering implementation.
Right now, far too much knowledge of filtering is embedded directly into
innd and nnrpd, and what I want to see is a clean API that says I'm
starting up, I'm changing modes, I'm closing down, or here's an event, and
then code in the generic filter layer that walks through all the
registered filters and passes along the events that they're interested in.

Separately, the current implementation of how we talk to Perl needs to be
reworked, but that's specific to just the Perl stuff.  (And the Tcl stuff
needs to be either ripped out or redone entirely; it doesn't even work
with current versions of Tcl.)

Russ Allbery (rra at             <>

    Please send questions to the list rather than mailing me directly.
     <> explains why.

More information about the inn-workers mailing list