RFE: .so filters
John Keeping
john at keeping.me.uk
Fri Jan 10 18:20:52 CET 2014
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.
More information about the CGit
mailing list