On Sat, Feb 25, 2006 at 12:52:16AM -0800, Loren Wilton wrote: > 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?
The results are exactly the same.
> 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.
There's nothing hackish involved, but I don't have performance numbers.
> 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?
None, and yes. Having the code as plugins instead of in EvalTests just moves
where the code lives, and allows for code to be disabled or swapped out.
> 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.
I think that's pretty easily doable (add load_plugin() calls to
M::SA::init()) if we wanted to go that route. For eval rules, it would
at least let us have a standard API, and clean up the PerMsgStatus object,
though I like the idea of having plugins be unpluggable. :)
--
Randomly Generated Tagline:
"Communist revolutionaries taking over the server room and demanding
all the computers in the building or they shoot the sysadmin."
- Today's BOFH Excuse
pgpAzRyYBomBZ.pgp
Description: PGP signature
