From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 9 Jan 2014 22:34:26 +0100
Subject: RFE: .so filters
Message-ID: <CAHmME9p6nE36-4PWxZTvSdZ0=mUu0CGBh4aRkr3KBaeiNH8reg@mail.gmail.com>

Hey folks,

I'm thinking about this filtering situation w.r.t. gravatar and
potentially running multiple filters on one page. Something I've been
considering is implementing a simple dlopen() mechanism for filters,
if the filter filename starts with "soname:" or "lib:" or similar, so
as to avoid the fork()ing and exec()ing we currently have, for high
frequency filters. The idea is that first use of the filter would be
dlopen()'d, but wouldn't be dlclose()'d until the end of the
processing. This way the same function could be used over and over
again without significant penalty.

In my first thinking of this, the method of action would be the same
as the current system -- "int filter_run(int argc, char *argv[])" is
dlopen()'d, executed, and it reads and writes to the dup2()'d file
descriptor. Unfortunately, the piping in this introduces a cost that
I'd rather avoid. In the case of gravatar (or more generally, email
author filters), we'd be better off with a "char *filter_run(int argc,
char *argv[])", that can just return the string that the html
functions will then print. This, however, breaks the current filtering
paradigm, and might not be ideal for filters that enjoy a stream of
data (such as source code filters). This distinction more or less
points toward coming up with a library API of sorts, but I really
really really don't want to add a full fledged plugin system. So this
has me leaning toward the simpler first idea.

But I'm undecided at the moment. Comments and suggestions are most welcome.

Jason