DevelopmentProceduresR1 5 » History » Revision 13
Revision 12 (Anonymous, 2006-12-29 12:43) → Revision 13/15 (Anonymous, 2006-12-29 12:43)
h2. == 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: h3. === 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. h3. === The code === It builds without _too_ ''too'' many warnings ;-). The fact that it _has_ ''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 :-) h3. === 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). h3. === Project group === * Overall: What persons, other than Jan, are SVN commiters? What other people are accountable, and for what? see DevelopersList h3. === 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)