module API redesign
- Current module API is not well defined and does not provide sufficient abstraction
- As a result, modules are not isolated and must know about internals of other modules (e.g. modules resetting request state must also reset
- Mixing wire-format-generating modules with modules relying on
req.*_selectedarrays leads to weird bugs (one example: !842 (merged), !851 (merged), !859 (merged))
- Lua modules seem to be slow (because of the way how C code calls Lua?)
- #363 Modules need generic way to persist own state
- #432 Modules need ability to not respond at all (for response rate limiting)
- #483 Modules currently cannot generate answer if no NS is responding
- #447 (closed) New server selection system should expose and use API instead of being hard-wired
- #396 (closed) SERVFAIL answer can still contain bogus RRsets
- #471 low-level protocol stuff is hard-coded (incorrectly)
- #36 make sure new API does not get in the way when implementing parallel queries
- #527 modules need a way to cooperate with fine-grained logging
- #418 engine object access - I don't know if this requirement will be still valid after redesign, but let's think about it
- #264 error reporing from modules sucks
- #234 (closed) a way to cooperate between modules??? e.g. for DNAME support???
- attempt to move
reorder_RR()into module, ideally in a form of policy action so it can be triggered on per-client basis - what API would be necessary?
Design a new API for modules in a way which prevents bugs stemming from bad API usage from ever repeating again.
Implementation is expected to be a long-term project, but we need proper design first. Hopefully #447 (closed), #535 and other tasks planned for 2020 will provide us sufficient experience for better API design.