List for cgit developers and users
 help / color / mirror / Atom feed
From: Jason at zx2c4.com (Jason A. Donenfeld)
Subject: RFE: .so filters
Date: Fri, 10 Jan 2014 19:00:16 +0100	[thread overview]
Message-ID: <CAHmME9pY5q-7+-b04RsH6kPpTGRwiE8sQqXUViyq7S4FH_Aa_Q@mail.gmail.com> (raw)
In-Reply-To: <20140110172052.GP7608@serenity.lan>

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!


  parent reply	other threads:[~2014-01-10 18:00 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-09 21:34 Jason
2014-01-09 22:29 ` mailings
2014-01-09 22:58 ` john
2014-01-10  1:41   ` Jason
2014-01-10  2:11     ` Jason
2014-01-10  4:26       ` Jason
2014-01-10  9:06       ` john
2014-01-10 15:57         ` Jason
2014-01-10 17:12           ` bluewind
2014-01-10 17:20             ` john
2014-01-10 17:43               ` mricon
2014-01-10 18:00                 ` Jason
2014-01-10 18:00               ` Jason [this message]
2014-01-10 17:57             ` Jason
2014-01-10 20:03               ` bluewind
2014-01-10 20:11                 ` john
2014-01-10 20:25                   ` bluewind
2014-01-10 20:36                     ` john
2014-01-10 20:56                       ` bluewind
2014-01-11  2:37                         ` Jason
2014-01-11  2:34                 ` Jason

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAHmME9pY5q-7+-b04RsH6kPpTGRwiE8sQqXUViyq7S4FH_Aa_Q@mail.gmail.com \
    --to=cgit@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).