From mboxrd@z Thu Jan 1 00:00:00 1970 From: john at keeping.me.uk (John Keeping) Date: Fri, 10 Jan 2014 17:20:52 +0000 Subject: RFE: .so filters In-Reply-To: <52D029F9.40805@xinu.at> References: <20140109225802.GM7608@serenity.lan> <20140110090639.GN7608@serenity.lan> <52D029F9.40805@xinu.at> Message-ID: <20140110172052.GP7608@serenity.lan> 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 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 ":" 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.