On Fri, Jan 10, 2014 at 6:20 PM, John Keeping <j...@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! _______________________________________________ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit