HUP handling: a thought

[Alan DeKok]

  Let's give up on HUP entirely.  Instead, we can implement something like:

http://www.linuxappliancedesign.com/projects/rta/

  I like the idea of configuration via SQL, but I don't like the idea of
a fast server doing SQL queries for configuration.  And caching the
results of the SQL queries just adds more complexity.

  The solution, I think, is to invert the problem.  Instead of making
the server do SQL queries to get its configuration, have the SQL queries
get the configuration from the internal data structures of the server.
The "rta" project above does this.  It's only about 1k LoC, which is nice.

  On the downside, it's not thread-safe, and only supports UPDATE and
SELECT, it requires that the rows be in arrays (for the most part), and
it has hard-coded limits on the number of rows, columns, name lengths, etc.

  My thought was to have a look at doing something similar, but with
support for INSERT, DELETE, and removing the hard-coded limitations.

  e.g. have each table as a balanced red-black tree.  Each leaf is a
"row".  Each row is a data structure, with accessor functions.  The
server code can just access the data structures directly, without
worrying about the whole SQL overhead.  The SQL code can use the
accessor functions to get the actual data.

  It may take a bit of magic to handle insertions && deletions in a
thread-safe way, but it could work...

  Alan DeKok.
--
  http://deployingradius.com       - The web site of the book
  http://deployingradius.com/blog/ - The blog