> One big plugin would be better than the current split. The current
> split has no solid technical rationale behind it.
>
> - allows eval rules to not be loaded. arguably, most of them will always
be
> enabled, but some could be disabled. DNSEval, for instance, is only
useful
> in net mode. If you're going to run in local-only mode, drop off the
eval
> tests that require DNS.
>
> So I'd like to get some consensus about whether or not we want to persue
this
> or if the branch should just be deleted and that's that. Thoughts?
Without looking at the code, and as something of an outsider, some thoughts
that may be useful:
1. Is there any notable rule efficiency difference between being an eval
and being a plugin? If so, and if it is a negative performace impact by
moving to a plugin, then it might be a bad idea to do it. But then, that
would indicate that either plugins are generally a bad idea, or that the
interface needs improvement.
2. If there isn't any notable performance difference, then this amounts to
an interface change. Assuming the evals use standard plugin interfaces
(assuming plugin interfaces ARE standard), then fewer interfaces is probably
a good thing. If the evals require a bunch of hackish special interfaces to
work, maybe it is a bad idea.
3. Splitting evals into multiple sets: Theo above mentions two obvious sets:
net rules and non-net rules. That might be a sufficient split.
4. Not splitting evals into separate rules: what effect would this have on
trying to priortize and short-circuit rules? Would it be possible to run
some rules in a package and not others?
5. It would probably be good to consider the idea of a "welded plugin" that
can't be unplugged and doesn't need to be explicitly plugged in someplace.
That way hunks of core stuff could safely use a standard interface, and you
don't have to worry about "what happens if all of the rule processors are
unplugged" or the like. I assume you would do this by loading some very
specific plugins during normal initialization code, rather than in some
place exposed to a user's fingers.
Loren
