DevelProblemAndSolution » History » Revision 6
Revision 5 (moo, 2007-08-14 05:05) → Revision 6/19 (moo, 2007-08-14 07:28)
[[PageOutline]] = Developmenet Problem And Solution = This page is meant to list Problem And Solutions implementing lighttpd. Any simple feature requests without solution should goes be go to [/trac/newticket ticket system]. = Redundant FastCGI/SCGI etc = == Problem == In lighttpd 1.4, most of the source code of mod_cgi, mod_scgi and mod_proxy were cut'n'pasted from mod_fastcgi. Why problem: Redundant code make it hard to maintain. == Solution == Combine them into mod_proxy_core and add protocols around it * 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 Why: scgi/fastcgi/ejb/http or whatever, are just protocols that we can use to send requests to and get response from backend. == Status == Implemented in 1.5.0 = Redundant and simple config handling = == Problem == The current config handling is done in core and plugin. The core parse it, convert the config into a conditional tree, and the plugin pick on of the values (use PATCH) and use it. Why problem: It's sure easier to fix the 1 core instead of all the plugins, the plugin is still handling too much config handling logical and i't hard to improve. == Solution == 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? == Status == Scheduled but not done, and is likely to be post pound to next major release. = .htaccess = == Problem == Many users want .htaccess or whatever named config file(s) sit(s) in document root or its sub dir. Neets: 1. vhost users can do no harm creating such file 2. limited config settings 3. has to be dynamic loaded. i.e., it makes affect when the file is updated without restarting lighttpd Improvements: 1. high performance, e.g.: "cached" 2. robust, e.g.: syntax error won't stop the server == Solution == No full solution yet from the view of the current source, as the following condition must (or may) be supported first: 1. clean config parsing with no memory leak (already) 2. dynamic config updating 3. versioned config: multiple clients may still referenced to current config nodes while the new one is being loaded Cautions: * avoid blocking operation (e.g.: disk io) reloading the file == Status == Feature requested.