Lighttpd

Assumptions¶

As the Lighttpd 1.5.x branch is starting, there are a couple of deficiencies in the development process that should be addressed.

The overall impression of the quality of Lighttpd 1.4.x as a product can vary quite a lot depending on where you're looking. So, seeing Lighttpd in retrospect:

Basic design, features, performance¶

There is no denying that "less is more" sometimes, Lighty being one of those cases. The basic design laid out by Jan is ambitious enough to provide a good number of features, yet retaining the "lightweight" overall feel of the program.

• Overall: Good.

The code¶

It builds without too many warnings ;-). The fact that it has a test framework is just super.

• The tests need to be maintained (maybe assigned/delegated to a specific developer).
• Successfully executing the tests should be a part of the release procedure :-)

Documentation¶

We have several up to date tutorials on the wiki, that's great. But for reference?

• Most of the documentation could move from the main web page to the wiki (to enable joint maintenance).

Project group¶

• Overall: What persons, other than Jan, are SVN commiters? What other people are accountable, and for what? see DevelopersList

TODOs¶

1.5.x is meant to

• fix internals which are blocking us from moving forward.
• do big changes that can't be done on 1.4.x-stable branch.
• merge most if not all duplicated code, which helps a lot on code maintaining/improving

the list below is meant for discussion.

• combine mod_fastcgi, mod_cgi, mod_scgi and mod_proxy into mod_proxy_core
  and protocols around it. They all cut'n'pasted from mod_fastcgi anyway.
  • the core provides
    • config handling
    • connect/retry on failure
    • fork/restart worker child on dead. (easier to improve native win32 support)
    • balancing
    • x-sendfile
  • the protocol backends take care of
    • preparing the environment (most cgi env code can be shared)
    • encode/decode data
    • handle io
• introduce a new io-subsystem which allows filtering content incoming and
  outgoing data
  • mod_uploadprogress can track the progress of an upload
  • mod_deflate can compress content
  • mod_multiplex can reroute content to other connections
  • mod_layout can replace tags in the outgoing stream
  • consider support for asynchronous file io (most likely emulated using threads rather than native aio calls)
• make the core aware of max-workers
  • combines server-status
  • synchroniced logfiles
  • perhaps make it memcache/shm/mmap based for cluster-wide stats
• combine most of config handling into core, including:
  • alloc/free plugin data
  • init default values
  • insert values from config (into plugin data)
  • patch(pick) values from plugin data for connection.
    this is done by calling a function ptr, but we can kill the string comparisons, lower or higher performance?
• apply %n to other config option.
  (such as document root. users might get confused as to what does or doesn't support %n, but it seems hard to apply all the options.)
• find a way to solve module order problem:
  • sort the "user enabled module" by the builtin "ordered module list", but 3rd party module have no luck on this way.
  • or add more "handling stages", and depends on "stage order" instead of "module order". this is a bit too complex.
  • sparsely assign each module a numeric id and use this to determine loading order.
  • or ... (and your solution here)