I'm finishing up a Lua bindings module to libopendkim, as the internal
opendkim-lua is not suitable for usage outside the opendkim daemon.
https://github.com/barracudanetworks/lua-opendkim
I've implemented all or nearly all of the libopendkim API. The module builds
against and runs on Lua 5.1 (including LuaJIT), 5.2, and 5.3. It has no
build or runtime dependencies other than Lua and libopendkim. More
importantly, it seemlessly supports asynchronous DNS via Lua closures and
coroutines.
Callback APIs like set_key_lookup install a trampoline. When a callback is
issued, the relevant parameters are stored. When the bindings encounter
DKIM_STAT_CBTRYAGAIN, any pending Lua closures are loaded, executed, the
results stored, and the function which returned CBTRYAGAIN is restarted.
When the internal C callback is re-executed, it retrieves the stored
results.
All of this is done so that Lua closures can yield, which is necessary for
integration with various non-blocking I/O frameworks. Because the Lua 5.1
API doesn't support the lua_callk/lua_yieldk API available in 5.2 and 5.3,
the bindings are composed of a C module and a Lua script module. The Lua
script portion interposes itself in front of the C bindings, and ensures
that the closures are executed in a yieldable context.
A sample script is included: regress/verify. It depends on my cqueues
asynchronous event module for the DNS lookups. But any event loop or DNS
interface could be substituted.
My next task is to implement an alternative to dkim_chunk, which is not
restartable.
I've only built and tested the work on OS X and Ubuntu, but I maintain my
own Lua modules--e.g. cqueues, luaossl, lunix--on many different platforms
(BSDs, Solaris, AIX), and I'll try to do the same here.
NOTE: When building, don't forget to set CPPFLAGS, LDFLAGS, SOFLAGS, LIBS,
etc. None of that is automated, yet; only Lua installation detection. See
the README.md for build examples for Linux and OS X.
Received on Fri Apr 10 2015 - 01:11:02 PST