the problems:
a) my SEQ system isn't the fastest (P1/200; i would prefer my G4 to run it, but w/o a working libEQ ... well ... :-)
b) also i would like to do an alternate interface, but don't want to interfere with the existing algorithms.
so i had some ideas:
1) move the packet filtering stuff to a (kernel) module.
2) put the packet analysing stuff and the calculations in a library.
or maybe even more libraries.
3) module support for SEQ
what are the reasons:
with (1) the packet filtering runs in kernel mode, so it will not get interrupted (so easily) if it "doesn't want to" and it should have more ressources availible, or have more control over them. actually doing something like ipchains was my basic idea.
idea (2) should make it possible, to make different alternate clients, for example a C based Xlib only version. or even a
TTY only version for very very special things.
ok, for point (3) the idea is, only to load things that are needed.
if i don't want the "special AC tracking and hunt down" module, but instead need the "how to kill flippy 1000 times an hour" and configure this using a file, like apache does it for example.
additional thoughts:
i like C++ and Qt, but they grew a lot in the last years, and IMHO a C/Xlib (maybe Xt) based solution should be more suitable for smaller machines. i know they are a bit more complicated to do, because i did Xlib/Xt programming, and was delighted when i started with Qt.
also maybe more people could "donate" work to this project. some may like to shift the bits in the kernel, others prefer the analysis part, and last but not least some may like to work on GUI interfaces. maybe some even start to add skins to SEQ, with a site like "skins.seq.org" ... ack ... ;-)
[putting on my fire resistance gear ... ;-)]