RFE: .so filters

[john at keeping.me.uk (John Keeping)]

On Fri, Jan 10, 2014 at 06:12:25PM +0100, Florian Pritz wrote:
> On 10.01.2014 16:57, Jason A. Donenfeld wrote:
> > On Fri, Jan 10, 2014 at 10:06 AM, John Keeping <john at keeping.me.uk> wrote:
> >>
> >> This seems drastically over complicated.
> > 
> > So here's the situation. There's a lot of "state" that we're taking
> > advantage of in using processes that terminate, that needs to be
> > replicated:
> 
> Isn't this (fast scripting with lots of features) when people normally
> start using lua?

I would have no problem including LuaJIT for this sort of thing.  There
was even a PoC for using Lua to format Git log messages a year or so
ago.

I was also wondering if supporting "unix:/path/to/socket" would be
useful, then the filter would connect on a Unix socket, run and
disconnect, on the assumption that the administrator has a daemon
running to do the filtering.

If we're introducing this "<type>:<spec>" support then it would be good
to do it in a reasonably generic way so that any types that add new
dependencies can be compiled out easily.  Maybe a table like this?

struct filter_handler handlers[] = {
    { "unix", open_unix_socket_filter, close_unix_socket_filter },
    { "persistent", "open_persistent_filter, close_persistent_filter },
#ifndef NO_LUA
    { "lua", open_lua_filter, close_lua_filter },
#endif
};

I might have a look at the Lua case over the weekend if no one beats me
to it.