RFE: .so filters

[Jason A. Donenfeld]

On Fri, Jan 10, 2014 at 6:20 PM, John Keeping <john at keeping.me.uk> wrote:
>
> 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.

This has few benefits, and you still have the out of band signaling
issues. Sysadmins don't want to run more daemons.

>
> 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
> };

This would make more sense. Look at the commit I just merged to master
where I split filters out into filter.c. This would be the place for
such a function pointer table.

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

Cool. Please take in mind the design considerations in the email I
just sent to Florian with the tree functions... Before you begin, take
a peak at jd/gravatar and jd/persistent. Can't wait to see what you
come up with!