Ideas¶

• Table of contents
• Ideas
  • Generic things
  • Get hackers and companies in touch
  • Angel
  • Config structure
    • Options
    • Internal options
    • Actions

Generic things¶

• Use ragel for parser generation
• 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!
• Allow dynamic logfiles by passing logfile path to logthread instead of logpointer

Get hackers and companies in touch¶

• http://www.cherokee-project.com/contribute.html - Bounty Hunting, get a company to spent a few bucks on things they want and ask community to write a module or extension and earn the money, nice idea! Users may submit their patches/modules and submit it to the devs, who then decide what gets implemented and who wins the price.

Angel¶

• should use a separate config file
  • manages sockets for graceful restart
• plugins (e.g. for fcgi spawning)

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 additional 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 list of actions
• If conditional is true execute subaction
• call a special handler (provided by some module)
• call a backend balancer (provided by some module)

every action returns one of the following codes:

• ERROR - an internal error, stops connection handling
• GO_ON - nothing special happened
• COMEBACK - come back later, remember current position
• WAIT_FOR_EVENT - wait for vrequest wakeup (li_vrequest_joblist_append), remember current position