Well, mostly curiosity and a bit of hacker instinct, I guess. More concretely I was hoping to understand the underlying implementation of the packet filtering process to be able to reason about performance on a deeper level than "rules with lots of hits go on top".
My concrete application, if you want to call it that: It's been irking me for a while that in SmartConsole the presentation of the rules is deeply tied up with their implementation. This has led me to wonder if one couldn't build an alternative, more declarative interface, with the generation of the actual policy and optimization based on past rule hits taken care of by some piece of translator software. And this is where INSPECT comes in, cutting out the middleman mgmt_cli: It's definitely possible to do this via the existing tools, generating an Original Flavor ruleset from a declarative specification, but if possible it'd be better to avoid that detour. No dependencies regarding specific interface implementations, better reasoning about performance, hell, maybe even greater potential for optimization due to lower-level access. And yeah, greater potential for accidentally breaking things - I guess that's why you don't release documentation, isn't it?
