Project

General

Profile

Actions

Ideas » History » Revision 1

Revision 1/7 | Next »
icy, 2008-10-11 17:43


Ideas

Generic things

  • Use ragel for parser generation
  • Kick automake, probably use cmake instead
  • Split off nice tools into separate trees (spawn-fcgi, fcgi-stat-accel)
  • Use glib2 for containers and other things (modules, logging, ...?)
  • Never use global variables. Never!

Angel

  • should perhaps use a separate config file
    • define sockets / ssl options there? so sockets are maintained by angel for graceful restart?
  • plugins (e.g. for fcgi spawning)
  • perhaps a thread for error logging so error messages do not overlap?

Config structure

  • Generic backend
  • Old config style frontend
  • Lua frontend
  • Linear request handling without confusing conditional blocks (still with conditionals of course)
  • A nice interface to load/unload addtional config options (e.g. for sql-vhosts)
  • Better interface for asynchronous config handling (again for sql vhosts)

Options

struct option

We have some different structures for options:
  • Boolean (gboolean)
  • Integer (gint)
  • String (GString*)
  • Array (GArray*) - an ordered list of sub options
  • Hashtable (GHashTable*) - mapping from strings to sub options

For some things like rewrite we used associate arrays till now we could use an array of (key, value) pairs, perhaps use a special syntax for that ( "abc": "xyz" for ordered key-value pairs instead of "abc" => "xyz" for hashtables).

Internal options

Every module can define a list of options (identified by name like "debug.log-something"). For each option there is a gpointer entry in a per connection table, in which the module can find the needed value by an index.

The definition for a option includes:
  • Name
  • Type (the same values as for option + perhaps a value for "custom")
  • Two functions: parse_option and free_option (see below)
Two ideas for the index:
  • Modules register every option manually and save a returned index in there plugin structure.
  • Modules define a list of options and use a module-base-index (from plugin structure) + the local index for there list.

As it may be very useful for a module to have more than a "option struct", e.g. to safe filedescriptors (access.log), so we register every possible option with an option-specific parser. The default is to just use the value from the option struct.
This parser returns a gpointer, which will be put in the corresponding place in the connection table if it the options gets set.
To enable unloading of options there is also an free_option func which should release the memory.

Actions

In the current lighttpd versions options are used to control which backend handles a request - this often depended on the order of loaded modules and some other things only a few people knew (or knew where to find).
We want to replace this with "actions": we explicitly call some functions and know what they will do.

There are some different types of action:
  • Set config option
  • Execute sublist
  • If conditional is true execute sublist
  • call a special handler (provided by some module)
every action returns one of the following codes:
  • ERROR - an internal error, stops connection handling
  • GO_ON - nothing special happened
  • BREAK - we finished a step like doc-root finding and want to skip other doc-root handling actions
  • FINISHED - we now know how to handle the request. stop config handling here
  • WAIT_FOR_EVENT - come back later, remember current position

BREAK breaks all sublist handling until a "special" list is hit; the simple config will have hardcoded special lists, the lua will have dynamically ones.

Updated by icy over 15 years ago · 1 revisions