DevelopmentProceduresR1 5 » History » Revision 4
Revision 3 (moo, 2006-04-12 12:33) → Revision 4/15 (moo, 2006-04-12 12:41)
== 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? === TODOs === 1.5.x is meant to fix internals which are blocking us from moving forward. 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 * retry on failure * balancing * x-sendfile * the protocol backends take care of * preparing the environment * 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 * 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?